head 1.1; access; symbols; locks http:1.1; strict; comment @# @; expand @b@; 1.1 date 2004.03.03.11.03.18; author MarkusDolensky; state Exp; branches; next ; desc @none @ 1.1 log @2nd Annual Report @ text @ࡱ>  jlKMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@@ jbjbqq  q`^l    xxx8\D5A\l# &1(N1R1h1=DXMRX@@@@@@@@@@@@@@,D F Ax\T:<<"\T\T AcPPR1h1 l#ccc\T\PR1xh1@@c, PP\T@@cckV@@$Tx.!IQY .5A5A! 1Gc1G.c 2nd Annual Report Contract N HPRI-CT-2001-50030Start date of contract 1 November 2001End date of contract 31 October 2004RTD Project Title Astrophysical Virtual ObservatoryWebsite address  HYPERLINK "http://www.euro-vo.org" www.euro-vo.orgName of CoordinatorDr. P.J.QuinnE-Mail address HYPERLINK "mailto:pquinn@@eso.org" pquinn@@eso.org Partnership Summary Participant Number (Coordinating partner as participant N1) Name of Participating Organisation Role in Project*1European Southern ObservatoryCO2Space Telescope European Coordinating FacilityCR3University of EdinburghCR4Centre National de la Recherche Scientifique Dlgation AlsaceCR4University Louis PasteurCR5Centre National de la Recherche Scientifique Dlgation ParisCR6The Victoria University of ManchesterCR * LSF-IHP: a research infrastructure funded for access under the IHP programme LSF-TMR: a research infrastructure funded for access under the TMR programme LSF-OTH: a research infrastructure outside the IHP or TMR programmes IND: an industrial or commercial enterprise OTHER: other types of participant  TOC \o "1-3"  1.0 Executive Summary  PAGEREF _Toc475074920 \h 6 1.1 Objectives  PAGEREF _Toc475074921 \h 6 1.2 Results  PAGEREF _Toc475074922 \h 6 2.0 Scientific and technical performance  PAGEREF _Toc475074923 \h 7 2.1 Summary of project objectives for year 2  PAGEREF _Toc475074924 \h 7 2.2 Technical Progress Work Area 0 Program Management  PAGEREF _Toc475074925 \h 8 2.2.1 Program Management WP 0.1  PAGEREF _Toc475074926 \h 8 2.2.2 Phase B Plan WP 0.2  PAGEREF _Toc475074927 \h 8 2.2A Technical progress - Work Area 1 Science  PAGEREF _Toc475074928 \h 11 2.2A.1 Definition of the AVO Science Reference Mission - WP 1.1  PAGEREF _Toc475074929 \h 11 2.2A.2 Definition of the AVO Scientific requirements - WP 1.2  PAGEREF _Toc475074930 \h 11 2.2A.3 Pilot implementation of selected science cases - WP 1.3  PAGEREF _Toc475074931 \h 12 2.2B Technical progress - Work Area 2 Interoperability  PAGEREF _Toc475074932 \h 14 2.2B.1 Inclusion of archives in the interoperability system WP 2.1  PAGEREF _Toc475074933 \h 15 2.2B.2 Running of tests and evaluation of results WP2.2  PAGEREF _Toc475074934 \h 15 2.2B.3 Implementation of new functionalities and standards WP2.3  PAGEREF _Toc475074935 \h 16 2.2B.4 Evaluation of interoperability tools WP2.4  PAGEREF _Toc475074936 \h 18 2.2C Technical progress - Work Area 3 Technology  PAGEREF _Toc475074937 \h 18 2.2C.1 WP3.1 Grid Technology  PAGEREF _Toc475074938 \h 19 2.2C.2 WP3.2 Storage/Compute Technology  PAGEREF _Toc475074939 \h 20 2.2C.3 WP3.3 Database Technology  PAGEREF _Toc475074940 \h 20 2.2C.4 Connections to other work areas.  PAGEREF _Toc475074941 \h 21 2.2C.5 Connections with other projects.  PAGEREF _Toc475074942 \h 21 2.3 Planned Activities and Actual Work  PAGEREF _Toc475074943 \h 21 2.3.1 Work-package 0.1: Program Management  PAGEREF _Toc475074944 \h 21 2.3.2 Work-package 0.2: Phase B Plan  PAGEREF _Toc475074945 \h 21 2.3.3 Work-package 1.1: Definition of the AVO Science Reference Mission  PAGEREF _Toc475074946 \h 22 2.3.4 Work-package 1.2: Definition of the AVO Scientific requirements  PAGEREF _Toc475074947 \h 22 2.3.5 Work-package 1.3: Pilot implementation of selected science cases  PAGEREF _Toc475074948 \h 22 2.3.6 Work-package 2.1: Inclusion of archives in the interoperability system  PAGEREF _Toc475074949 \h 22 2.3.7 Work-package 2.2: Running of tests and evaluation of results  PAGEREF _Toc475074950 \h 23 2.3.8 Work-package 2.3: Implementation of new functionalities and standards  PAGEREF _Toc475074951 \h 23 2.3.9 Work-package 2.4: Evaluation of interoperability tools  PAGEREF _Toc475074952 \h 23 2.3.10 Work-package 3.1: Grid Technologies  PAGEREF _Toc475074953 \h 24 2.3.11 Work-package 3.2: Storage/Compute Technologies  PAGEREF _Toc475074954 \h 24 2.3.12 Work-package 3.3: Database Technology  PAGEREF _Toc475074955 \h 25 2.4 Planned Activities for Year 3  PAGEREF _Toc475074956 \h 25 2.4.1 Work Area 0 Activities  PAGEREF _Toc475074957 \h 25 2.4.2 Work Area 1 Activities  PAGEREF _Toc475074958 \h 25 2.4.3 Work Area 2 Activities  PAGEREF _Toc475074959 \h 25 2.4.4 Work Area 3 Activities  PAGEREF _Toc475074960 \h 26 3.0 List of Deliverables  PAGEREF _Toc475074961 \h 27 4.0 Exploitation and dissemination of results  PAGEREF _Toc475074962 \h 28 4.1 Conferences:  PAGEREF _Toc475074963 \h 28 4.2 International Press:  PAGEREF _Toc475074964 \h 28 4.3 Presentations and Papers:  PAGEREF _Toc475074965 \h 28 4.4 AVO Website Access:  PAGEREF _Toc475074966 \h 30 5.0 Management and coordination aspects  PAGEREF _Toc475074967 \h 31 5.1 Project Communications  PAGEREF _Toc475074968 \h 31 5.1.1 Project meetings  PAGEREF _Toc475074969 \h 31 5.1.2 Technical meetings  PAGEREF _Toc475074970 \h 31 5.1.3 Intranet  PAGEREF _Toc475074971 \h 31 5.1.4 Telephone Conferencing  PAGEREF _Toc475074972 \h 31 5.2 Manpower allocation and utilization  PAGEREF _Toc475074973 \h 35 5.3 Project Budgets  PAGEREF _Toc475074974 \h 35 5.4 Attribution of tasks  PAGEREF _Toc475074975 \h 36 6 Appendices  PAGEREF _Toc475074976 \h 37 Appendix A1 Travel Authorization 1  PAGEREF _Toc475074977 \h 37 Appendix A2 Travel Authorization 2  PAGEREF _Toc475074978 \h 39 Appendix A3 Travel Authorization 3  PAGEREF _Toc475074979 \h 41 Appendix B1 DMBS Technology for the AVO  PAGEREF _Toc475074980 \h 43 Abstract  PAGEREF _Toc475074981 \h 43 1. Introduction  PAGEREF _Toc475074982 \h 43 2. Scientific Requirements  PAGEREF _Toc475074983 \h 44 3. The Astronomical Data Explosion  PAGEREF _Toc475074984 \h 45 3.1 Grid Computing  PAGEREF _Toc475074985 \h 46 3.2 Data Centres  PAGEREF _Toc475074986 \h 47 3.3 Architectural Implications  PAGEREF _Toc475074987 \h 47 4. Resource Registry  PAGEREF _Toc475074988 \h 48 5. Standards for Interoperability  PAGEREF _Toc475074989 \h 48 5.1 VOTable  PAGEREF _Toc475074990 \h 49 5.2 Query Language  PAGEREF _Toc475074991 \h 49 6. Cone Searches and Catalogue Cross Matching  PAGEREF _Toc475074992 \h 49 6.1 Cone Search  PAGEREF _Toc475074993 \h 50 6.2 Cross-Matching  PAGEREF _Toc475074994 \h 51 6.3 Spatial Join Algorithms  PAGEREF _Toc475074995 \h 51 7. Data Exploration and Data Mining  PAGEREF _Toc475074996 \h 52 7.1 Data Mining Packages  PAGEREF _Toc475074997 \h 53 7.2 Data Exploration  PAGEREF _Toc475074998 \h 53 7.3 Problem Areas  PAGEREF _Toc475074999 \h 53 8. Distributed Databases  PAGEREF _Toc475075000 \h 55 8.1 Distributed Join  PAGEREF _Toc475075001 \h 55 8.2 Data Warehouse Concept  PAGEREF _Toc475075002 \h 56 9. Alternatives Database Structures  PAGEREF _Toc475075003 \h 56 9.1 Flat File Systems  PAGEREF _Toc475075004 \h 56 9.2 Object-oriented DBMS  PAGEREF _Toc475075005 \h 57 9.3 XML DBMS  PAGEREF _Toc475075006 \h 59 9.4 Object-relational DBMS  PAGEREF _Toc475075007 \h 59 9.5 Column-oriented Storage  PAGEREF _Toc475075008 \h 59 10. DBMS Evaluations  PAGEREF _Toc475075009 \h 60 10.1 Packages Evaluated  PAGEREF _Toc475075010 \h 61 10.2 Desirable Features  PAGEREF _Toc475075011 \h 61 10.3 Summary  PAGEREF _Toc475075012 \h 61 11. Summary of Recommendations  PAGEREF _Toc475075013 \h 62 Structure of the Virtual Observatory  PAGEREF _Toc475075014 \h 62 Indexing and Cross-matching  PAGEREF _Toc475075015 \h 62 Data Exploring and Mining  PAGEREF _Toc475075016 \h 62 DBMS Packages  PAGEREF _Toc475075017 \h 63 Appendix A: Evaluation of Postgres, MySQL, and DB2  PAGEREF _Toc475075018 \h 63 A.1 Documentation  PAGEREF _Toc475075019 \h 63 A.2 Installation, Configuration, and Tuning  PAGEREF _Toc475075020 \h 64 A.3 General Usability  PAGEREF _Toc475075021 \h 65 A.4 Data Loading  PAGEREF _Toc475075022 \h 68 A.5 Spatial Indexing  PAGEREF _Toc475075023 \h 69 A.6 Performance: Joins using R-trees  PAGEREF _Toc475075024 \h 70 A.7 Simple Query Performance  PAGEREF _Toc475075025 \h 71 A.8 Summary  PAGEREF _Toc475075026 \h 71 References  PAGEREF _Toc475075027 \h 72 Appendix B2 Grid Middleware for the Virtual Observatory  PAGEREF _Toc475075028 \h 73 Abstract  PAGEREF _Toc475075029 \h 73 What makes a Grid  PAGEREF _Toc475075030 \h 73 Different grids for different commodities  PAGEREF _Toc475075031 \h 74 Intragrids, extragrids  PAGEREF _Toc475075032 \h 75 Standards bodies  PAGEREF _Toc475075033 \h 75 Software for computational grids  PAGEREF _Toc475075034 \h 76 Web services  PAGEREF _Toc475075035 \h 76 Contextual web services and OGSI  PAGEREF _Toc475075036 \h 77 WS-Reference Framework  PAGEREF _Toc475075037 \h 78 OGSI and OGSA  PAGEREF _Toc475075038 \h 78 OGSI implementations  PAGEREF _Toc475075039 \h 79 Condor  PAGEREF _Toc475075040 \h 80 Software for data grids  PAGEREF _Toc475075041 \h 80 GridFTP  PAGEREF _Toc475075042 \h 80 Reliable File Transfer Service  PAGEREF _Toc475075043 \h 80 Replica managers  PAGEREF _Toc475075044 \h 81 OGSA-DAI and LDAS  PAGEREF _Toc475075045 \h 81 Storage resource broker  PAGEREF _Toc475075046 \h 82 Access control  PAGEREF _Toc475075047 \h 82 Public key infrastructure for grids  PAGEREF _Toc475075048 \h 82 Authenticating requests to services: transport and message-level security  PAGEREF _Toc475075049 \h 84 Avoiding replay attacks: WS-Secure conversation  PAGEREF _Toc475075050 \h 84 Authorization  PAGEREF _Toc475075051 \h 85 Strategies for engaging with the grid  PAGEREF _Toc475075052 \h 86 M.1 No grid products at all  PAGEREF _Toc475075053 \h 86 M.2 Everything based upon GGF standards  PAGEREF _Toc475075054 \h 86 M.3 Grid services only as leaves of the service tree  PAGEREF _Toc475075055 \h 86 M.4 Leaf grid service plus pervasive GSI and GridFTP  PAGEREF _Toc475075056 \h 87 M.5 Grid conventions rule inside intragrids  PAGEREF _Toc475075057 \h 87 Comparisons  PAGEREF _Toc475075058 \h 87 Summary of recommendations  PAGEREF _Toc475075059 \h 88 Web services  PAGEREF _Toc475075060 \h 88 OGSI/WS-RF and OGSA  PAGEREF _Toc475075061 \h 88 Data-grid software  PAGEREF _Toc475075062 \h 88 Access control  PAGEREF _Toc475075063 \h 88 Refererences  PAGEREF _Toc475075064 \h 89 Appendix C Cost Statements  PAGEREF _Toc475075065 \h 91  1.0 Executive Summary The AVO contract (HPRI-CT-2001-50030) began on 1 November 2001. The project aims within a three-year work program to lay the scientific and technical basis for an operational virtual observatory in Europe. The project consists of three main work areas (Science, Interoperability and Technology), utilizes approximately 54 man years of effort involving more than 50 staff spread over six partner organizations and consortia. 1.1 Objectives The second year of the project had 5 main objectives: Complete hiring of AVO staff Plan, develop and implement the first demonstration of AVO technologies in January 2003 at an AVO Science Working Group meeting held at Jodrell Bank Observatory As a member of the International Virtual Observatory Alliance, participate in a coordinate demonstration and exhibition of VO technologies and systems at the International Astronomical Union General Assembly held in Sydney, Australia in July 2003 Coordinate and align AVO technical and interoperability work programs with the priorities set out by the International Virtual Observatory Alliance (IVOA) at there January 2003 meeting and provide AVO representation in the IVOA working groups for AVO strategic areas of work Prepare and submit FP6 proposals for components of the AVO Phase B work program (EURO-VO). 1.2 Results All of these objectives have been fully met within this reporting period. The AVO demonstration of new VO functionality during the January 2003 SWG meeting at JBO (AVO First Light), our contribution to the definition, development and deployment of new international data standard for Virtual Observatories in coordination with the IVOA and our successful demonstration and outreach actions a the IAU General Assembly are the highlights of the second year. 2.0 Scientific and technical performance 2.1 Summary of project objectives for year 2 The specific project objectives for AVO in the second year were as follows: Complete hiring of AVO staff Plan, develop and implement the first demonstration of AVO technologies in January 2003 at an AVO Science Working Group meeting to be held at Jodrell Bank Observatory As a member of the International Virtual Observatory Alliance, participate in a coordinate demonstration and exhibition of VO technologies and systems at the International Astronomical Union General Assembly held in Sydney, Australia in July 2003 Coordinate and align AVO technical and interoperability work programs with the priorities set out by the International Virtual Observatory Alliance (IVOA) at there January 2003 meeting and provide AVO representation in the IVOA working groups in AVO strategic areas of work Prepare and submit FP6 proposals for components of the AVO Phase B work program (EURO-VO). Project work programs were verified and initiated at the first AVO Project Meeting held in Edinburgh on 15 November 2001. The minutes of this meeting (and all other AVO project meetings) can be found at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/ReportsAndMinutes" http://www.euro-vo.org/twiki/bin/view/Avo/ReportsAndMinutes. The AVO work program was adopted and Work Area Manages assigned as follows: Work Area 0: Program Management - manager: P.Quinn (ESO) Work-package 0.1 Program Management Work-package 0.2 AVO Phase B definition Work Area 1: Science manager: P.Benvenuti (STECF) Work-package 1.1 AVO SRM definition Work-package 1.2 AVO Science Requirements Work-package 1.3 Pilot implementations Work Area 2: Interoperability manager: F.Genova (CDS) Work-package 2.1 Archive inclusion Work-package 2.2 Test evaluations Work-package 2.3 New functionality Work-package 2.4 Evaluation of tools Work Area 3: Technology manager: A.Lawrence (U.Edinburgh) Work-package 3.1 Grid technologies Work-package 3.2 Storage and Computation Work-package 3.3 Database technology From September 2003, P.Benvenuti left ESA and was replaced by R.Albrecht as acting head of the ESA Space Telescope European Coordination Facility and acting work area manager for AVO Work Area 1. Dr. Albrecht will be replaced by the new AVO scientist as manager of WA1 in December 2003. The technical progress of the AVO work program will be described by major Work Areas and work packages as outlined above. 2.2 Technical Progress Work Area 0 Program Management Work area 0 contains two work packages that define the overall management of the AVO work program and the preparation process of the Phase-B work program starting in the second half of 2004 (EURO-VO). 2.2.1 Program Management WP 0.1 The main activities of WP 0.1 in the second year of the AVO program can be summarized as Oversight of completion of project-wide recruitment Preparation of AVO Year 1 Report Organization of project-wide meetings to coordinate and monitor work activities with particular emphasis on preparation of AVO technology and capabilities demonstrations. Full project meeting were held in Cambridge, UK on 14 May, 2003 and at ESO from 10-11 December 2003. Full minutes of this meeting, with associated documents and actions are available at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/ReportsAndMinutes" http://www.euro-vo.org/twiki/bin/view/Avo/ReportsAndMinutes, together with minutes and documents from specific work area meetings and tele-cons. Interface to other international VO efforts for the purposes of collaborative and coordinated actions leading to VO capabilities on the international scale. The International Virtual Observatory Alliance (IVOA) was formed in June 2002 following a join action by AVO, ASTROGRID and NVO. It now contains 14 member projects which hold joint coordination meetings on a regular basis ( HYPERLINK "http://www.ivoa.net" http://www.ivoa.net). AVO was represented at the IVOA executive meeting in Seattle USA on 9/10 January 2003 and in Sydney on 23 July as well as IVOA Interoperability Meetings in May and October 2003 (see  HYPERLINK "http://www.ivoa.net/twiki/bin/view/IVOA/IvoaEvents" http://www.ivoa.net/twiki/bin/view/IVOA/IvoaEvents for full details and minutes). Coordination of AVO efforts with projects in the GRID community through AVO participation in the GGF-9 meeting in Chicago from 5-8 October 2003. Development and maintenance of the AVO web pages at  HYPERLINK "http://www,euro-vo.org" http://www,euro-vo.org. Design, development and deployment of AVO PR material with the assistance of the ESO and ESA/STECF PR staff based at ESO headquarters in Munich. Two press releases were prepared and distributed in 2002/2003: Exploring the Digital Universe:  HYPERLINK "http://sci.esa.int/science-e/www/object/printfriendly.cfm?fobjectid=29078" http://sci.esa.int/science-e/www/object/printfriendly.cfm?fobjectid=29078 and AVO First Light  HYPERLINK "http://sci.esa.int/science-e/www/object/printfriendly.cfm?fobjectid=32538" http://sci.esa.int/science-e/www/object/printfriendly.cfm?fobjectid=32538 Within WP 0.1, the AVO Technical Lead (M.Dolensky) did the systems engineering and coordination work necessary for the deployment of the AVO demonstration system at JBO in January 2003. 2.2.2 Phase B Plan WP 0.2 Following the announcement of calls for FP6 in early 2003, preparations began for a set of specific proposals for AVO Phase-B (EURO-VO) following meetings by the AVO Executive Committee and advice provide by the Commission. The European Virtual Observatory (EURO-VO) project will be an integrated and coordinated program of work designed to provide the European astronomical community with the data access, research tools and systems, research support, data interoperability standards, data-flow practices and data centre coordination, necessary to enable the exploration of the digital, multi-wavelength universe resident in European and international astronomical and astrophysical data archives. The project is based on the research, development experience and prototypes produced in the FP5 RTD project entitled Astrophysical Virtual Observatory (AVO) [HPRI-CT-2001-50] and the science case experience of the Enhancing Access to Large Facilities initiative ASTROVIRTEL [HPRI-CT-1999-00081]. The EURO-VO program seeks to support and deploy Virtual Observatory (VO) capabilities to data centres and observatories across the entire electromagnetic spectrum. It will therefore be closely coupled with the two other major integrating and networking activities for astronomy in FP6: OPTICON and RADIONET. EURO-VO will act as a natural hub for coordination and integration of the new, GRID-enabled, VO research infrastructure that will be essential to the success of future large European community programs in astronomy (e.g. ALMA, OWL, SKA and Planck). The EURO-VO will consist of three new organizational structures which will meet the objectives of the total work program and which will provide a platform for a long term European VO research infrastructure and capability. There are three fundamental EURO-VO objectives: EURO-VO-Objective 1: Technology take-up and full VO compliant data and resource provision by astronomical data centres in Europe EURO-VO-Objective 2: Support to the scientific community to utilize the new VO infrastructure through dissemination, project support, tool prototyping and VO facility-wide resources and services EURO-VO-Objective 3: Further development and refinement of VO technologies to meet new scientific challenges The three EURO-VO structures that will meet these objectives are: The EURO-VO Data Centre Alliance (DCA): a collaborative and operational network of European data centres who, by the uptake of new VO technologies and standards, will publish data, metadata and services to the EURO-VO and who will provide a research infrastructure through the adoption and application of GRID-enabled processing and storage facilities. The EURO-VO Facility Centre (VOFC): an organization that provides the EURO-VO with a centralized registry for resources, standards and certification mechanisms as well as community support for VO technology take-up, VO dissemination and scientific program support using VO technologies and resources. The EURO-VO Technology Centre (VOTC): a distributed organization that coordinates a set of research and development projects on the advancement of VO technology, systems and tools in response to scientific and community program needs.  The EUVO-VO structures will be realized within the schemes, priorities and instruments of FP6 by three coordinated and interdependent proposals: VO-INT: An I3 proposal under the Integrating Activities aspects of the Research Infrastructures Action. The VO-INT proposal will integrate aspects of all three infrastructural components of the EURO-VO. It will contain the totality of the work of the EURO-VO FC, approximately half of the work program of the EURO-VO DCA and approximately one third of the work program of the EURO-VO TC which focus explicitly on astronomy-specific metadata issues and VO science tools. VO-NET: An I3 proposal under the Communication Network Developments aspects of the Research Infrastructures Action. This I3 contains the technological and infrastructural deployment aspects of the EURO-VO DCA not covered by VO-INT which focuses on the coordination and interoperability-enabling aspects of the DCA as a networking activity. VO-TECH: An Integrated Project under the IST thematic priority area of solving problems with GRID technologies. The requested resources will complete the work program of the EURO-VO TC with respect to specific developments of VO technologies that implement the GRID paradigm or which depend directly on GRID middleware developments supported by other aspects of FP6. This mapping of the EURO-VO work program into the schemes, priorities and instruments of FP6 aligns the nature of the intended work and overall program goals with the capabilities, requirements and stated goals of FP6. The mapping seeks to optimize the utilization of community and consortium resources to maximize the enhancement in research capabilities for the European astronomical community. The VO-INT proposal was submitted on 15 April 2003 and the VO-NET on 7 May 2003. Details and copies of both proposals can be found at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/FpSix2003" http://www.euro-vo.org/twiki/bin/view/Avo/FpSix2003 . We were informed in June/July that both proposals had been unsuccessful at obtaining funds. This is a major setback for the AVO project and jeopardizes the European involvement in the IVO effort. Several member organization of the AVO project are now reassessing the path forward with EURO-VO, its strategic importance and possible reapplications in FP6. 2.2A Technical progress - Work Area 1 Science 2.2A.1 Definition of the AVO Science Reference Mission - WP 1.1 This work package aims at defining the Science goals against which the AVO scientific impact can be measured. 2.2A.1.1 Regular AVO Science Working Group Meetings - WP 1.1.1 The AVO Science Working Group (SWG) was appointed in Year 1 and currently includes 31 proper members plus 22 extra members of the AVO SWG at large. The latter is being kept fully informed about the development of the AVO Project and is being invited to express its opinion and submit suggestions. However, differently from the AVO SWG proper, no financial support for participation in meetings is provided. During the 2nd year the SWG met once, on January 20 and 21 at the Jodrell Bank Observatory in the UK. During the meeting, the AVO First Light demonstration was given (see below: WP 1.3). The SWG organized itself into three working sub-groups: Cosmology (convener: Dave de Young), Galaxy Structure & Formation (convener: Pepi Fabbiano), and Stellar and Planets (convener: Timo Prusti). The purpose of the sub-groups was to identify science topics in these areas and note capabilities required to speed up the science discovery process. The sub-groups met in breakout sessions and then reported back with their suggestions, which were then considered for the definition of the AVO science requirements and future AVO demonstrations (see below: WP 1.2 and 1.3). The minutes of SWG meetings are available on-line at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/SwgReports" http://www.euro-vo.org/twiki/bin/view/Avo/SwgReports. 2.2A.2 Definition of the AVO Scientific requirements - WP 1.2 This work package aims at defining the scientific requirements for the implementation of the AVO. It concerns the type of data, their quality, their level of description and the requirements for high-level algorithms and software procedures. Actions 1 and 2 have strong interfaces with actions in WPs 2.1, 2.2 and 2.3 of WA 2 Interoperability. 2.2A.2.1 Further definition of science requirements for implementation in annual demonstrations of new capabilities - WP 1.2.1 The definition of the science requirements proceeded at two levels: input from the AVO SWG and input from the WA1 scientists. As regards the former, the three SWG sub-groups (Cosmology, Galaxy Structure & Formation, and Stellar and Planets: see above) identified many science topics in their areas, as detailed in the January 2003 meeting minutes. The implications for future AVO capabilities were summarized as such: access to photometric tools (e.g., redshift determination), access to spectral data sets, ability for user upload of data/models, integration of model data (e.g., evolutionary tracks), access to theoretical data (e.g., atomic line data), access to statistical techniques (e.g. fuzzy cross-correlations). This input was taken into account in the preparation for the AVO annual demonstration in 2004 (see below: WP 1.3.1). WA1 scientists used the input received from the SWG and their own astronomical expertise to further define the AVO science requirements. In particular, the suggestion of the SWG at the January 2003 meeting to include a Galactic science case led to a detailed study of possible scenarios, with careful consideration of the available data and tools (in collaboration with WA2). Results of this work will be presented at the January 2004 science demonstration. 2.2A.2.2 Full discussion and definition of data quality metrics and assessment process in coordination with IVOA discussion of these topics - WP 1.2.2 This discussion, started in Year 1, continued in Year 2. Participation of key WA1 people to International Virtual Observatory Alliance (IVOA) meetings, where these topics are being defined and discussed within specialized working groups, insured that WA1 is kept fully aware of the global picture. Concerning astrometry, a discussion in one of the preparatory meetings to the January 2004 science demonstration, has led to the idea of defining a standard procedure (or a toolbox) for solving the astrometric interoperability issue among different archives, that is a tool to allow image alignment and registration between images taken by different instruments. This is a pressing and common problem most astronomers have to deal with and such a tool would be a real asset. Work on this will start after the January 2004 science demonstration. The increasing availability of multi-object and objective prism/grism spectroscopic data was discussed in Year 1 as an issue: how should these data be extracted and presented within the AVO? In Year 2 we addressed the latter point and used the newly defined IVOA Simple Spectral Access (SSA) standard to work on a simple and effective way to match multi-object spectra with the corresponding images. This will be one of the key components of the January 2004 science demonstration. 2.2A2.3Test the WP 1.2.1 and 1.2.2 definitions against the data set included in the AVO Phase A implementation - WP 1.2.3 This action, deferred from last year to be addresses after the 1st demo (see below), was taken in Year 2 at the January 2003 science demonstration and afterwards. The AVO First Light showed that the feedback between defining science requirements, data types and quality and the implementation of the above was working well. Science was leading the way by coming up with real-life cases and the development of the necessary tools, in collaboration with WA2, followed that. Preparations for the January 2004 demonstration, which has an even stronger science component, confirmed that a working mechanism is in place for this testing. 2.2A.3 Pilot implementation of selected science cases - WP 1.3 This work package aims at implementing in a pilot fashion a few selected AVO science projects. Work in this area was done at two levels: the January (SWG) and July (International Astronomical Union: IAU) 2003 science demonstrations and preparations for the January 2004 science demonstration. The first two SWG meetings indicated that the 1st AVO demonstration should aim at showing the AVO capabilities on a genuine multiwavelength database, the latter quality being more important than the extension of the field of view. In order to obtain a rapid progress in the 1st implementation, the investigators involved in the Great Observatories Origins Deep Survey (GOODS) Programme were contacted and agreed to allow usage of GOODS data. These cover the Chandra Deep Field South (CDFS) and Hubble Deep Field North (HDFN) fields. The first AVO science demonstration (AVO First Light) was on January 20 and 21 at the Jodrell Bank Observatory in the UK, concurrent with an SWG meeting. The demonstration was also tied to a media event and press release (full details available at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/AvoWork20012003" http://www.euro-vo.org/twiki/bin/view/Avo/AvoWork20012003). The demonstration was a success. It dealt with a variety of astronomical data at X-ray, infrared, optical, and radio wavelengths, both from space-based and ground-based observatories, and showed the capability of the AVO to: access very large images at different wavelengths; show the available data, with proper information (metadata) to allow users to select the data of interest; locate, recognize, combine, extract information from existing catalogues using flexibly Uniform Content Descriptors (UCDs); create catalogues on-the-fly from astronomical images using the Astronomy Catalogue Extractor (ACE) Web Service developed by AstroGrid (running SExtractor, Bertin & Arnouts 1996); plot the spectral energy distribution (SED) of astronomical sources on-the-fly using the SED tool developed at ESO. Many of these functionalities took advantage of the IVOA discussion on VO standards. Three science scenarios were also highlighted, to show the potential of the AVO prototype: 1. high redshift environment; 2. identification of supernova candidates; 3. radio observations of the HDFN and the associated flanking fields. A second AVO science demonstration was held in July 2003 at the IAU General Assembly in Sydney, Australia, in coordination with demonstrations of other international VO projects. The AVO prototype was improved and new functionalities were added (see WP 2.3). 2.2A.3.1 Preparation for implementation of trial VO science cases in year 3 - WP 1.3.1 Considerable amount of work in Year 2 went into the preparation of the January 2004 AVO science demonstration. As mentioned above (WP 1.2.1), the SWG input was taken into account. In particular, after careful consideration also of the available data, it was decided that the second AVO science demonstration would have had the following new features: very strong science case; inclusion of a Galactic science case; access to spectroscopic data; data cubes access and visualization; use of new IVOA standards; new tools, developed by WA2 based on the science requirements; access to photometric tools; access to any VO-compliant data collection and archive. 2.2B Technical progress - Work Area 2 Interoperability One basic task of WA2 is building prototypes to federate and integrate heterogeneous, distributed data. The second year work program consisted in identifying new functionalities, testing the prototypes by running science cases and evaluating the results. This has been organized at the AVO project level, by developing a series of science demonstrations. WA2 team has been developing software following WA1 science specification, in coordination with WA3, to implement successive versions of the pilot integration tool. These were successfully demonstrated in January 2003 at the Science Working Group AVO First Light meeting in Jodrell Bank, and in July 2003 at the International Astronomical Union General Assembly in Sydney, in coordination with demonstrations of other international VO projects. The last part of the period was devoted to preparing the next demonstration, which will be presented to the Science Working Group in January 2004 in Garching. Additional science tests have been performed by astronomers invited in Strasbourg (M. Kontiza and E. Kontizas from Athens, R.G. Mann from Edinburgh), who the tools in their expertise domains, in collaboration with WA2 Strasbourg staff, and suggested new functionalities. A document comparing VO-flavoured tools was also produced (R.G. Mann, M.G. Allen). The AVO pilot project developments are opened for community usage by maintaining the current version of the AVO prototype accessible on the AVO site with full documentation. Moreover, the new functionalities developed for the AVO prototype are progressively implemented in the public version of Aladin, and are thus widely available for community usage. The second basic task of WA2 is the study and definition of common, internationally agreed data exchange standards and tools for interoperability. Common standards shared by all VO projects are the key for a truly international VO, since they allow for easy communication and data exchange between archives and services. This is a very successful international endeavour of the International Virtual Observatory Alliance (IVOA). The first international VO standard, VOTable, has been one key element allowing data exchange and tool integration in the international VO demonstrations. The first version of the Uniform Content Descriptors (UCDs) has also been used in the AVO demonstration. The Simple Image Access Protocol (SIAP), first proposed by the US NVO project, has been successfully implemented. Il allows access to international SIAP-compliant archives, but the usefulness of a more sophisticated, hierarchical data tree was beautifully demonstrated in the AVO prototypes. It is proposed to include this kind of functionalities in the international standard. UCDs and hierarchical data tree are the basis of information discovery implementation in the AVO prototype, by defining metadata describing image data sets and catalogue contents. The definition and evolution of interoperability standards is managed through lively email discussions, with also face to face meetings. Two international meetings have been organized en 2003, in Cambridge (UK) in May and in Strasbourg (France) in October. The WA2 team participates very actively to the development of IVOA interoperability standards. Another highlight of WA2 second year activity is the rapid development of international collaboration between VO projects beyond Europe. In particular, WA2 collaborated with VO-India for the development of the VOTable plotting facility VOPlot, and with other VO projects for implementing links to international archives in VizieR and Aladin. Since the Sydney demonstration, VOPlot has been integrated in the AVO pilot implementation. WA2 Interoperability consists in four Work Packages: WP2.1 Inclusion of archives in the interoperability system WP2.2 Running of tests and evaluation of results WP2.3 Implementation of new functionalities and standards WP2.4 Evaluation of interoperability tools 2.2B.1 Inclusion of archives in the interoperability system WP 2.1 The VizieR catalogue Browser and the Aladin integration tool gather metadata about catalogues, data archives and image servers. Using this metadata, the user interface provides access to catalogues, images and remote resources for browsing, downloading data and visualizing images and catalogues in a single environment. During the first year of the project, a set of European archives, representative of a variety of techniques (space/ground based, images/spectra, wavelengths from X-rays to radio), have been included in the VizieR system. In addition this year, active links to the XMM archives have been implemented, giving direct access to the data stored in the archive at ESA/Villafranca. The cross-identification of the list of ISO observations in SIMBAD has been completed (except for some cases which are still being discussed with ESA), to test more advanced interoperability functionalities to and from the ISO archive. The preliminary discussion on the ESA/Herschel mission has been continued with scientists from several French institutes which participate in the mission, to assess future inclusion of Herschel in the VO context (in particular, inclusion of complex, extended objects; usage of a community-specific coordinate system). C. Bots PhD also allows assessment of several aspects of the inclusion of extended objects observed in this wavelength range in the VO. One member of WA2 team (L. Cambrsy) has been coopted on to the Planck project Working Group which deals with VO aspects. In addition, implementation of links to international archives has been actively discussed, in particular with the Australian and Canadian VO projects. Links to the MACHO database, hosted by the Australian National University Supercomputing Facility in Canberra, were implemented before the IAU demonstration in Sydney. On the same schedule, Aladin was made compatible with Simple Image Access Protocol-compliant archives, which allowed easy interface to US NVO-compliant datasets and later to ESA SIAP-compliant archives (ISO and XMM) in preparation for the AVO January 2004 demonstration. The implementation of links to the Canadian Galactic Plane Survey is under way for the January 2004 AVO demonstration. 2.2B.2 Running of tests and evaluation of results WP2.2 The science demonstrations have of course been the major milestones in the running of tests on science cases, and WA1 has gathered reactions and new specifications from the Science Working Group. The demonstrations performed at the International Astronomical Union in Sydney have also been an excellent occasion to get comments from the world-wide astronomy community. In addition, several European scientists stayed in Strasbourg for a few weeks on Invited Professor positions of the Universit Louis Pasteur or on WA2 invitation as experts. They made intensive science tests of the tools in their respective domain of expertise. R.G. Mann (Royal Observatory of Edinburgh), in collaboration with M. Allen (WA2), made a detailed assessment of the usage of several available tools to study X-ray detected extremely red objects. This assessment included the AVO First Light demo tool, VOPlot and several other VO-flavoured tools, and is thus also part of Work Package 2.4. Mann /Allens report, Doing Science with prototype Virtual Observatory tools, is available on line on the AVO Web site. M. Kontiza (National and Kapodistrian University of Athens) and E. Kontizas (National Observatory of Athens) assessed in particular the usage of the first beta version of VOPlot to study stellar populations in globular clusters and in the Small Magellanic Cloud. These detailed assessments have proven very useful to propose ergonomics improvements and new functionalities. The comments and suggestions for new functionalities have been assessed for technical feasibility by WA2 and have been very useful to improve VO tools. WA2 scientists actively participated to the assessment and definition of January 2004 demonstration topics led by WA1. This demonstration will emphasize in particular the usage of spectral data and access to radio data cubes. 2.2B.3 Implementation of new functionalities and standards WP2.3 2.2B.3.1 New functionalities The development of new functionalities in the Aladin demo prototype for the First Light January 2003 demo have been completed: Capability to access very large images Image cut-out service in the Aladin image server A hierarchical view of the available data, with proper information (metadata) at each level of the tree allowing users to select the data of interest for them A more flexible usage of the Aladin plane stack, allowing users to create folders and to build their own grouping of data Flexible usage of UCDs to locate, recognize, combine, extract information from tables (filter function) Usage of VOTable for data exchange to and from Aladin, and plug-in of Spectral Energy Distribution (SED) tool developed at ESO. A dialog using VOTable between Aladin and the Astronomy Catalogue Extractor Web Service developed by AstroGrid (running SExtractor, Bertin & Arnouts 1996) was also demonstrated. Several of these new functionalities took advantage of the international discussion on interoperability standards (see below). An upgrade of the prototype functionalities has been performed for the IAU July demonstrations, allowing easier further extensions and facilitating usage: Clean plug-in with Java applications using VOTable, allowing easy interface with software modules developed by AVO or other VO teams, in particular proper integration of VOPlot, SED and ACE Improvement of the metadata tree display and usage using forms Improvement of the filter interface ergonomics Client interface to data services compliant with the Simple Image Access Protocol (SIAP) Implementation of SIAP access to the Aladin image server In addition, a VOTable lite parser has been developed by WA2 and is publicly available. The collaborative work with the Indian Virtual Observatory team at the InterUniversity Centre for Astronomy and Astrophysics (IUCAA, Pune), led to the successful development of VOPlot, a versatile system for visualization of tabular data, which has been interfaced with the Aladin AVO prototype demonstrated in July 2003. The specification and software development were discussed in detail during visits of F. Ochsenbein and P. Fernique (WA2) in Pune in November 2002 and March 2003. Detailed science and technical specification and software development for the January 2004 science demonstration are on-going. The aim is to provide tools with the full capability to gather heterogeneous, distributed data, and launch analysis programs. One main extension on request of the Science Working Group is the inclusion of spectral data. Prototype access to data cubes will also be provided. A prototype cross-identification tool will also been implemented. Preparatory work on catalogued data distribution and computing on clusters of PC is under way, to check possible implementation of rapid cross-identification of very large catalogues. 2.2B.3.2 Standards and tools Standards and metadata are essential for a truly interoperable international Virtual Observatory. The first standard of the International Virtual Observatory Alliance, VOTable, has percolated very quickly in the international VO community, and has been widely used in all the VO demonstrations. It is also the key for inter-operation of software elements developed by different teams, for instance Aladin/ACE/SED in the AVO project and VOPlot/VizieR-Aladin in collaboration with VO India. More generally, VO demonstrations are an excellent test-bed for proposed standards. UCDs (see below) were also a key element of the AVO demonstrations, allowing users to discover, select and transform catalogued data (filter function). Another important feature for data discovery and data display has been the implementation of a view of the data model defined in the frame of the Image Distribues Htrognes en Astronomie project (IDHA selected in 2001 by the French Ministre de la Recherche, ACI GRID). This view organizes hierarchically the available data into a data tree, with proper metadata at each level of the tree, allowing users to knowledgeably select information for download and display. The current IVOA standard for image data access layer, the Simple Image Access Protocol (SIAP), gives access only to flat data lists, and discussion is under way in the relevant IVOA Working Group to implement some kind of hierarchical organization of data, taking advantage of lessons learnt from the AVO demonstrations. The January 2004 demo will use a prototype Simple Spectrum Access Protocol. Another area in which WA2 is very active is the definition and implementation of Uniform Content Descriptors (UCDs). A tool to access the UCD tree has been developed. UCDs are used by VOTable: UCDs describing the semantic meaning of each column are included in VOTable-compliant tables. WA2 team undertook a complete check of the first version of UCDs (UCD1), with respect to VizieR catalogues and tables (more than 3,500 catalogues including with more than 100,000 columns), in order to prune the complex, 1,400 item UCD tree. In addition, the team discussed with data providers from different domains of astronomy to check UCDs relevant to their domain. It was also proposed to implement a more flexible atomic structure (G.T. Rixon). A very lively discussion on the evolution of UCDs took place in 2003. The IVOA UCD Working Group formed a Steering Committee, which is the core group of people interested in the evolution and maintenance of UCDs. UCDs have to evolve to take into account checks and lessons learnt; on the other hand, UCDs could obviously be used to build an ontology of astronomy, and the next step could have been to jump towards a UCD syntax aiming at facilitating this latter usage. An ontology-facilitating proposal, UCD2, was prepared and discussed, and it appeared that this went too far from data providers requirements and would have been an obstacle to the generalization of UCD usage foreseen in the VO community. Thus a second proposal, UCD1+, is being prepared. WA2 team has been working very actively on the evolution of UCDs, syntax definition, and tests. The correspondence with UCD1 is being fully checked, and action has been taken to build an assignment tool. The UCD1+ proposal will be distributed to the Steering Committee by the end of 2003. WA2 has also been very active in the development of Web Services, to provide key functions from the CDS services: name resolver (including SIMBAD and VizieR names, and also names from NASA Extragalactic Database), VizieR access, astronomical coordinate translation, UCD resolver and access to the UCD list, GLU tag resolution. A SOAP lite library was also developed. Additional services will be made available in the future when needed. WA2 also participated actively to the discussion on resource registries: M.G. Allen was in charge of gathering science cases; harvesting of VizieR by OAI-compliant registries is also being implemented, as part of the NVO and AstroGrid demonstration in January 2004. Standards are discussed in the frame of IVOA Working Groups. CDS organized an Interoperability meeting in Strasbourg on October 16th-17th, 2003, which was attended by more than 120 persons (a huge increase in interest from about 30 participants to the first meeting in January 2002, which was also held in Strasbourg), with support from the OPTICON Thematic Network. WA2 staff also attended the preceding meeting in Cambridge (May 12th-16th, 2003). WA2 personal play a key role in several IVOA Working Groups; F. Ochsenbein leads VOTable WG. 2.2B.4 Evaluation of interoperability tools WP2.4 As explained earlier, this activity resulted in R.G. Mann and M.G. Allens report, Doing Science with prototype Virtual Observatory tools, which assesses the available functionalities in different VO tools. They demonstrate that a combination of these tools is already very close to provide full capability science analysis to deal with complex science questions, and propose improvements many of them have been already implemented in some of the tools. 2.2C Technical progress - Work Area 3 Technology The overall purpose of WA3 is to assess, develop, and deploy new technologies needed to construct a Virtual Observatory. These technologies are in three main areas - storage and compute technology, Grid technology, and database/datamining technology. This is a challenging task, as the background technology is evolving rapidly. This year we have completed several major milestones - completion of our studies on grid middleware and datamining technology, culminating in public reports with recommendations, and deployment of sufficient working implementations of key technology advances to help the AVO overall deliver a very successful demonstration of genuine new capacity to our international Science Working Group. The major remaining task before us is to complete design of a recommended architecture for the coming Euro-VO. Some more detail on the WA3 programme, and key reports, can be found at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree" http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree WA3 is under the overall management of A.Lawrence, at the University of Edinburgh, who is also the AstroGrid Project Leader. The AstroGrid consortium takes principal responsibility overall for AVO technologies. There are three sub-packages. WP3.1 (Grid Technology) is undertaken primarily by AstroGrid staff, and is managed by G.Rixon at the University of Cambridge. Progress in this area is however central to the future design of the European Virtual Observatory (Euro-VO), so staff in other work areas are kept informed, and several are closely involved. WP3.2 (Storage/Computer Technology) is undertaken primarily by staff at ESO, and is managed by A.Wicenec. Experiences at other data centres, including those outside the formal partnership, is however also collated. WP3.3 (Database Technology) is undertaken primarily by AstroGrid staff, and is managed by C.Page at the University of Leicester. There is considerable intersection with staff in other work areas. There is also a programme of WP3.3 work at TeraPix under the direction of Y.Mellier. To date this has been largely independent. 2.2C.1 WP3.1 Grid Technology 2.2C.1.1 Middleware This segment of our work has achieved significantly more than our objectives by this stage. The last year has seen very significant progress in two strands - deployment of web services, and trials of OGSA compliant grid middleware. This has culminated in the completion of one of our major milestones -  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree" \l "Formal_Reports_from_Work_Area_Th" a report and recommendations on grid midleware. During year one, various protocols and standards for web services stabilised and real-world deployments began to proliferate. In the meantime, it was clear that OGSA-compliant grid services were not yet sufficiently reliable or stable. We therefore began a working deployment with industry standard web-services, with the intention of subsequent re-engineering with grid services. Web-service deployment mostly centred round the building of the AstroGrid component infrastructure (ref) but also within the AVO demonstration suites (ref). The technologies used were XML, SOAP, and WSDL, operating over HTTP. We did not use UDDI, but, together with other VO projects worldwide, constructed our own registries - this has been a major focus of the  HYPERLINK "http://www.ivoa.net/twiki/bin/view/IVOA/WebHome" international standards effort during the last year. Web services however will not provide all the VO's requirements, as they are synchronous, stateless, and do not carry authentication information. Potentially, OGSI-compliant grid services solve this problem. We have therefore spent much of the year running experimental OGSI deployments. These have been successful, but OGSI is still not stable or reliable. Meanwhile, the IT industry standard is developing separate methods of solving the limitations of web services, known as Web Service Context, or WS-CTX. The protocols are not yet complete, but it seems likely that for the basic VO infrastructure we should build round WS-CTX rather than OGSI. We have also been testing other elements of Grid technology, many of which look much more likely to be deployed in Euro-VO - for example OGSA-DAI for querying, and GIS/CAS for authentication. Within AstroGrid, we have also been developing other key components of the VO infastructure - for example, a workflow system, the  HYPERLINK "http://wiki.astrogrid.org/bin/view/Astrogrid/AgCd07MySpace" MySpace virtual grid-storage system , and a Cocoon based portal "harness" through which a variety of components can present their user interfaces. 2.2C.1.2 Network studies During most of year two, this task was put on the back burner because of lack of staff effort, and other tasks taking higher priority. However, from October onwards, with the hire of C.Davenhall, we have re-started this task. There are two main strands to current work. The first is analysis of a large amount of existing network data involving the AVO partners, to identify bottlenecks and make recommendations. The second is a programme of improvements and tuning between partners - adjusting TCP parameters, installing GridFTP and tuning again, and so on. In early experiments, this has already improved real bandwidth by an order of magnitude. Much of this is a familiar story from other Grid projects such as Dante Perfmonit or GridMon, but in the case of astronomical data centres, we are additionally limited in practice by exit from and ingest to DBM systems and related software, such that disc I/O rather than internet bandwidth soon becomes the limiting factor. We also however have done experiments that show how to improved disc I/O by a factor of thirty, and will include such recommendations in our final report in this area, expected in Spring 2004. 2.2C.2 WP3.2 Storage/Compute Technology The original plan to deploy hardware to the various AVO sites has been abandoned pretty early in the project. Instead it has been decided to produce a report and recommendations for archiving and data center hardware. The main activities inside the consortium around hardware and system evaluation are distributed and part of other activities. A lot of activities in this area are carried out outside the consortium and even outside the astronomical community at large. In 2003 a number of publications and reports published by a number of groups have been studied and a number of private discussions have been carried out in order to collect the relevant information for the final report of WP3.2. The main sources of information are listed below the final report is due in February 2004. Since the area of storage solutions is evolving quite rapidly, reports are by definition outdated at the moment when they are published. Yet such reports are still valuable, because the collection of the information makes it more valuable than the single parts. Moreover some of the parts are evolving more rapidly than others. In particular the parts of the final report related to file systems and basic storage technologies are more stable, but also more complex to assess, since many of the possible solutions are highly dependant on the actual problems to be solved. Even in the pretty narrow domain of astronomical archives the boundary conditions may force the different groups to adopt different solutions. The main goal thus seems to be able to inter-connect the different solutions chosen by the different archives. For archives which will be established in the future the various solutions existing in the AVO community should be carefully assessed and if any possible one of those should be chosen. This requires that the existing solutions are documented in a way which makes it easy to carry out such an assessment. 2.2C.3 WP3.3 Database Technology Extensive studies in the performance of Database management systems and related technology has continued this year, mostly carried out within AstroGrid. This has culminated in the completion of one of our major milestones -  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree" \l "Formal_Reports_from_Work_Area_Th" a report and recommendations on datamining technology. . Part of the work this year has involved quantitative evaluation of a set of specific popular DBM systems. There is no single clear winner, advantages depending somewhat on the circumstances and requirements of a particular data centre. There are however some general problems with standard relational DBM systems and SQL interfaces for astronomical datamining, such as not naturally accommodating the necessary metadata, coping poorly with extremely large datasets, and inadequate mathematical, statistical, and graphical facilities. Many of these drawbacks are now being addressed by the international VO community, for example developing "Astronomical Data Query Language (ADQL)". It was also noted that column oriented storage, available in a minority of products, has strong advantages for data-intensive querying. Further work in the DBMS area has been carried out at the TeraPix centre in Paris, which this year has mostly been centred on WA2 topics. This work is therefore described in the WA2 report, although TerAPix staff effort is still formally accounted here within WA3. 2.2C.4 Connections to other work areas. Often, there is no clear distinction between work in WA2 and WA3, and the two areas collaborate closely. WA3 also works closely with WA1. The overall design for demonstration events and demonstration software suites is the responsibility of WA1, but in order to make these a reality, it relies on taking the R&D done in WA3 and WA2, and converting it into concrete deployments. Meanwhile, WA3 in general and AstroGrid in particular are building towards a robust general purpose component architecture which gives a framework in which WA1 can achieve its goals. 2.2C.5 Connections with other projects. The global nature of the VO has become ever more obvious, and this has now become formalised through the creation of the  HYPERLINK "http://www.ivoa.net/" International Virtual Observatory Alliance. The IVOA has set up a series of working groups, and holds twice yearly interoperability workshops. Some of these interactions are at political or scientific levels, but mostly they are on very detailed technical issues. WA3 work is closely aligned with the IVOA working group agenda. WA3 also has close interactions with other grid and e-science projects, especially within the UK e-science programme. The grid technology environment is evolving fast, and the most exciting new technology is not always the most reliable. We therefore have to keep two streams going - a conservative deployment stream, and a more high risk R&D stream. Astronomical recognition within this larger scene is improving. We have for example set up a "Birds of a Feather" group within the Global Grid Forum. 2.3 Planned Activities and Actual Work 2.3.1 Work-package 0.1: Program Management Planned ActivityCompleted?CommentsComplete Staff RecruitmentFullyAVO Scientist position candidate found and accepted with projected start date of 1 December 2003Submit Year 1 ReportFullyReport submitted and approvedInitiate international VO project linksFullyAVO staff present at IVOA Interoperability meetings, IVOA Working Group participation and coordinated demonstrations at IAU 2.3.2 Work-package 0.2: Phase B Plan Planned ActivityCompleted?CommentsPrepare and Submit FP6 proposals for EURO-VO componentsFully 2.3.3 Work-package 1.1: Definition of the AVO Science Reference Mission Planned ActivityCompleted?CommentsRegular Science Working Group meetingsFully 2.3.4 Work-package 1.2: Definition of the AVO Scientific requirements Planned ActivityCompleted?CommentsFurther definition of science requirements for implementation in annual demonstrations of new capabilities FullyFull discussion and definition of data quality metrics and assessment process in coordination with IVOA discussions on these topicsMostlyDiscussion still ongoing Further refinement following AVO demonstrations in January 2004Test the WP 1.2.1 and 1.2.2 definitions against the data set included in the AVO Phase A implementationMostly 2.3.5 Work-package 1.3: Pilot implementation of selected science cases Planned ActivityCompleted?CommentsPreparation for implementation of trial VO science cases in Year 3Fully 2.3.6 Work-package 2.1: Inclusion of archives in the interoperability system Planned ActivityCompleted?CommentsInclusion of international archivesFully Links to the MACHO database have been implemented in VizieR and through VizieR in Aladin SIAP-compliant archives include for instance NASA HEASARC SkyView 2.3.7 Work-package 2.2: Running of tests and evaluation of results Planned ActivityCompleted?CommentsPreparation of January 2003 and July 2003 scientific demonstrationsFullyAssessment of prototype by the running of tests FullyNew desirable functionalities were identified from Comments gathered during scientific demonstrations Trial science cases by visiting scientists Opening of the interoperability system to the communityFullyCurrent demonstration version is maintained on the AVO Web site New functionalities are incrementally implemented in the public version of Aladin, thus concurring to the production of science results in the community at large, e.g. Hierarchical data tree Filters Flexible plane stack VOPlot plug-in 2.3.8 Work-package 2.3: Implementation of new functionalities and standards Planned ActivityCompleted?CommentsNew functionalities developed On-goingIncremental development for the demonstrations Includes e.g. information discovery (using IDHA data model, UCDs and filters)Definition of standardsOn-goingFocus on VOTable, UCDs, data model, data access layer, resource registryInternational collaborationFullyDevelopment of and interface with VOPlot (VO India) IVOA WGs, with focus on VOTable, UCDs, data model, data access layer, Web services, resource registry 2.3.9 Work-package 2.4: Evaluation of interoperability tools Planned ActivityCompleted?CommentsComparative testsOn-goingFirst report produced 2.3.10 Work-package 3.1: Grid Technologies Planned ActivityCompleted?CommentsMiddleware assessment report and recommendationsFullyA preliminary version of this milestone was complete ahead of time, during year one. However, there have been continuing and considerable changes in the background technology, so that this work continued very actively. However we have completed a final report including recommendations as of January 2004.Network Analysis report and recommendation on strategic network investmentsPartlyDue to staff effort problems (slow recruitment, and a key staff member absent on military action) this task was temporarily put on the back burner. However it re-started successfully in October 2003 and we anticipate a report and recommendations in April 2004. Demonstration of working datagridFullyThis is an overall AVO task, with key contributions from WA3, which has been essentially completed through the software suite demonstrated to the Science Working Group in January 2004 2.3.11 Work-package 3.2: Storage/Compute Technologies Planned ActivityCompleted?CommentsDeploy Trial HardwareCancelledDue to decreased funds, this was not undertaken. Rather, each partner organisations is using its own resources internally to deploy and test hardwareStorage Assessment report and recommendationsPartlyInitially this task was centred purely around the ESO NGAST team. We decided however to expand its remit to include experiences and experiments of other partners. A revised completion date has been during Spring 2004. Architecture Assessment report and recommendationsOngoing (+30 months)This is now the key task in front of us during the next year, gathering what we have learned so far to conclude a top-level design for the Euro-VO that will follow on from the AVO project. We are aiming to complete this task in July 2004 2.3.12 Work-package 3.3: Database Technology Planned ActivityCompleted?CommentsDBMS Assessment report and recommendationsFullyA preliminary version of this milestone was complete ahead of time, during year one. However, substantial work has continued, and the final report brought back somewhat. We have completed the final report including recommendations as of January 2004. Working datamining system for external user testingFullyThis is an overall AVO task, with key contributions from WA3, which has been essentially completed through the software suite demonstrated to the Science Working Group in January 2004.  2.4 Planned Activities for Year 3 The activities planned for Year 3 are consistent with the work program contained in the description of work for the AVO Phase-A contract (HPRI-CT-2001-50030). 2.4.1 Work Area 0 Activities Ongoing program management including regular project meetings Coordination with international efforts through IVOA Coordination with Grid projects through IVOA GGF presence Preparation of FP6 proposals for 2004 Formation of EURO-VO alliance to strengthen EC proposals and commence EURO-VO work program in 2004 System Engineering/Management of AVO international demonstrations 2.4.2 Work Area 1 Activities Regular Science Working Group meetings Further definition of science requirements for implementation in annual demonstrations of new capabilities Preparation for implementation of last trial AVO science case Final definition of AVO Science Reference Mission Provide simple but powerful tools to facilitate exploitation of multiwavelength data 2.4.3 Work Area 2 Activities Regular interoperability meetings in coordination with IVOA effort with particular effort on VOTable, UCDs, data models, resource registries, Web Services Assessment and expansion of new functionalities to meet needs of coordinated science demonstrations and trial science cases, in particular, implementation of cross-identification functions Further development of new standards for data access and evolution of existing standards (e.g. UCDs, SIA and VOTable) Trial execution of science cases 2.4.4 Work Area 3 Activities Continues assessment of middleware, hardware and architecture choices Support of AVO demos with prototype implementations of IVO infrastructures and standards Trial execution of datamining and datagrid use cases via coordinated AVO demonstrations and IVOA activities 3.0 List of Deliverables The following table details the status of the project deliverables for the second twelve months according to the work program as specified in the contract. Associated or complementary products and reports are also listed. Work-packageDeliverableCommentsWP0.1Annual report DELIVERED: This reportWP0.2No scheduled deliverableWP1.1AVO Science Reference Mission DocumentSECOND DELIVERY: SWG Science Case Definition HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/SwgReports"http://www.euro-vo.org/twiki/bin/view/Avo/SwgReports WP1.2Definition of the AVO Scientific requirementsDELIVERED: SWG Science Requirements HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/SwgReports"http://www.euro-vo.org/twiki/bin/view/Avo/SwgReportsWP1.3Pilot implementation of selected science casesFIRST DELIVERY: AVO First Light  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/AvoWork20012003" http://www.euro-vo.org/twiki/bin/view/Avo/AvoWork20012003WP2.1Inclusion of new archivesDELIVERED MACHO SIAP-XMM, ISO, NVOWP2.2Science trial assessmentDELIVERED Mann/Allens report  HYPERLINK "http://www.euro-vo.org/pub/articles/ScienceWithProtoVOtools/ext.html" http://www.euro-vo.org/pub/articles/ScienceWithProtoVOtools/ext.html WP2.3Opening of the interoperability system for community usageDELIVERED Incremental release of demonstration software Incremental inclusion of new functionalities in Aladin Incremental standard definitionWP2.4No scheduled deliverableFirst report: Man/Allens document  HYPERLINK "http://www.euro-vo.org/pub/articles/ScienceWithProtoVOtools/text.htm" http://www.euro-vo.org/pub/articles/ScienceWithProtoVOtools/text.htm WP3.1Grid EvaluationDELIVERED Middleware assessment  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree" http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree PARTIAL POSPONED to 08/04 Network assessmentWP3.2Storage/Computer EvaluationPARTIAL POSPONED to 07/04 Storage Assessment reportWP3.3Database Technology EvaluationDELIVERED DBMS Report  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree" http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreaThree  4.0 Exploitation and dissemination of results The work of the AVO project team has been widely reported and presented during the past twelve months. The following section summarizes these dissemination activities. A comprehensive list of AVO publications, presentations and related articles can be found at  HYPERLINK "http://www.euro-vo.org/"  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/AvoPubArts" http://www.euro-vo.org/twiki/bin/view/Avo/AvoPubArts which includes public lectures and outreach activities at open days etc. 4.1 Conferences: The principal event of the past twelve months was the presence of the AVO project team members at the International Astronomical Union General Assembly held in Sydney from 13-26 July 2003. AVO team members made presentations at Joint Discussion 08 on LARGE TELESCOPES & VIRTUAL OBSERVATORY: VISIONS FOR THE FUTURE ( HYPERLINK "http://cdsweb.u-strasbg.fr/misc/jd_08.htm" http://cdsweb.u-strasbg.fr/misc/jd_08.htm ). AVO, as part of the IVOA, also took part in a coordinated demonstration of VO technologies and scientific capabilities which attracted a large audience and considerable feedback over the course of the assembly. AVO staff also took part in the 13th annual Astronomical Data Analysis and Software Systems meeting held in Strasbourg from 12-15 October 2003. This meeting was also associated with an IVOA Interoperability meeting and workshop on VO systems. Presentations and related information can be found at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/AvoPubArts" http://www.euro-vo.org/twiki/bin/view/Avo/AvoPubArts 4.2 International Press: The AVO project was featured in several press releases following the successful first demonstration of VO Technologies (AVO First Light) at Jodrell Bank Observatory in January 2003. Europes Silicon Skies Open Today:  HYPERLINK "http://www.nature.com/nsu/030113/030113-11.html" http://www.nature.com/nsu/030113/030113-11.html Exploring the digital Universe with Europes Astrophysical Virtual Observatory:  HYPERLINK "http://www.esa.int/export/esaCP/ESAVAKZ84UC_Life_0.html" http://www.esa.int/export/esaCP/ESAVAKZ84UC_Life_0.html 4.3 Presentations and Papers: The following is a list of AVO papers and associated publications given by AVO team members in the last twelve months. (see  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/AvoPubArts" http://www.euro-vo.org/twiki/bin/view/Avo/AvoPubArts). Progress Report on the AVO Project, M. Dolensky, ST-ECF Newsletter No. 32, Garching, November 2002 Toward an AVO Interoperability Prototype, M.G. Allen et al., 2003, ASP Conf. Ser., 295, 55 First Light For AVO, M. Dolensky, ST-ECF Newsletter, No. 33, 12, March 2003 The Astrophyscial Virtual Observatory AVO, P. J. Quinn et al., Abstracts of General Assembly of IAU XXV, JD08, 187, 2003 Architecture of the AVO Prototype, M. Dolensky et al., Abstracts of General Assembly of IAU XXV, JD08, 188, 2003 The Astrophyscial Virtual Observatory, M. C. Leoni, M. Dolensky, The Astropysical Virtual Observatory , Italian Physical Society LXXXIX, Parma, September 2003 Survey among Spectral Data Providers and Consumers, M. Dolensky, D. Tody, Astronomical Data Analysis Software & Systems XIII, Strasbourg, October 2003 TWiki - A Collaboration Platform for VO Projects, M. Leoni et al., Astronomical Data Analysis Software & Systems XIII, Strasbourg, October 2003 VO Access to Complex Data - MERLIN and Other Interferometry Archives, A. M. S. Richards et al., Astronomical Data Analysis Software & Systems XIII, Strasbourg, October 2003 Data valorisation in astronomy: from information networking to virtual observatory: F. Genova, Ensuring long-term preservation and adding value to scientific and technical data, Toulouse, November 5-7, 2002 (publication on CD-ROM) Interoperability in the CDS services : F. Genova, M. Allen, F. Bonnarel, T. Boch, S. Derriere, D. Egret, P. Fernique, F. Ochsenbein, A. Schaaff, M. Wenger, American Astronomical Society, 201st AAS Meeting, #08.04; Bulletin of the American Astronomical Society, Vol. 34, p.1105, 2002 Organisation of Datasets in Virtual Observatories: M. Allen, F. Bonnarel, T. Boch, P. Fernique, M. Louys, Large Telescopes and Virtual Observatory: Visions for the Future, 25th meeting of the IAU, Joint Discussion 8, July 17, 2003, Sydney, Australia Architecture of the AVO Prototype: M. Dolensky, M. Allen, K. Andrews, T. Boch, F. Bonnarel, S. Derriere, P. Fernique, M. Hill, M. Leoni, T. Linde, Large Telescopes and Virtual Observatory: Visions for the Future, 25th meeting of the IAU, Joint Discussion 8, July 17, 2003, Sydney, Australia The Astrophysical Virtual Observatory AVO : P.J. Quinn, P. Benvenuti, P. Diamond, M. Dolensky, F. Genova, A. Lawrence, Y. Mellier, Large Telescopes and Virtual Observatory: Visions for the Future, 25th meeting of the IAU, Joint Discussion 8, July 17, 2003, Sydney, Australia Organisation of Data Sets in Virtual Observatories: M. Allen, Astronomical Data Analysis Software & Systems XIII, Strasbourg, October 12-15, 2003 The AVO Prototype : P.J. Quinn, M. Allen, K. Andrews, T. Boch, F. Bonnarel, S. Derriere, M. Dolensky, P. Fernique, M. Hill, M. Leoni, A. Linde, A. Micol, B. Pirenne, A. Richards, A. Schaaff, G. Tissier, N. Walton, A. Wicenec, Astronomical Data Analysis Software & Systems XIII, Strasbourg, October 12-15, 2003 4.4 AVO Website Access: The following graphs represent the AVO website ( HYPERLINK "http://www.euro-vo.org" http://www.euro-vo.org ) access and utilization over the reporting period. The peak of activity and interest surrounding the AVO Year 1 Demonstrations (AVO First Light) are obvious features.  5.0 Management and coordination aspects 5.1 Project Communications Communications within the AVO project consists of four main components: 5.1.1 Project meetings These meetings take place once or twice per year and involve all work area and work package managers as well as staff reporting on work area activities. In year 2, the AVO Project Meetings was held at Cambridge on 14 May ( HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/AvoProj14052003" http://www.euro-vo.org/twiki/bin/view/Avo/AvoProj14052003) and at ESO from 11-12 December ( HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/AvoProjMeeting1112Dec2003" http://www.euro-vo.org/twiki/bin/view/Avo/AvoProjMeeting1112Dec2003). Minutes and actions associated with these project meetings, as well as related documents, can be found on the AVO web site under the links given. 5.1.2 Technical meetings Meetings on specific technical topics within a work area or across work areas are help on an adhoc basis as project needs dictate or as part of the IVOA meeting cycle. Interoperability meetings were held, in collaboration with IVOA projects, in May at Cambridge ( HYPERLINK "http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003" http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 ) and in October at Strasbourg ( HYPERLINK "http://www.ivoa.net/twiki/bin/view/IVOA/InterOpOct2003" http://www.ivoa.net/twiki/bin/view/IVOA/InterOpOct2003 ). 5.1.3 Intranet The AVO project has followed the lead of the ASTROGRID consortium and established an internet communication system based on technology know as TWIKI. This has proved to be extremely effective at facilitating and promotion project communications. The system now acts as an extensive historian of project evolution and a repository of project documents and products. The main entrance for the AVO intranet is  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/WebHome" http://www.euro-vo.org/twiki/bin/view/Avo/WebHome 5.1.4 Telephone Conferencing AVO makes extensive use of telephone conferencing for AVO Executive meetings (involving the six representatives of the AVO partners) and for communications with other VO projects through the International Virtual Observatory Alliance. The IVOA tele-cons frequently involve project representative from a large number of time zones (US east and west coast, UK, France, Germany, Russia, India, China, Japan and Australia). Minutes and actions from IVOA technical telephone conferences can be found under the top level links in the individual Work Area at  HYPERLINK "http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreas" http://www.euro-vo.org/twiki/bin/view/Avo/WorkAreas. The following lists the travels and meetings attended by each participant: Participant 1 and Co-ordinator: ESO No travels charged to EC. Participant 2: ESA AVO Demonstration Presentation of the AVO software prototype. Manchester, 19-22 January AVO Project and technical meeting. Cambridge, 14 May 2003 Participant 3: UEDIN AVO Demonstration preparations. Leicester, 6-15 November 2002 AVO/Astrogrid integration. Discussion and preparation of the AVO Demonstration, Cambridge 08-10 December 2002 AVO Meeting. Cambridge, 16 December 2002 AVO Technical Meeting, Preparation of the AVO demonstration in January 2003. Cambridge 14-17 December 2002. AVO Meeting with EC IST Directorate General. Brussels 14 January 2003 AVO Demonstration and Astrogrid Meeting. Manchester, 18-22 January 2003 AVO Project Meeting. Leicester, 18-19 February 2003 AVO Portal Working Group Meeting. Leicester, 24 February 2003 AVO Executive Meeting. Garching, 4-5 March 2003 IVOA Meeting. Cambridge, 12 May 2003 Participant 4: ULPS.CDS.OAS AVO Technical Meeting, Strasbourg 15 November 2002. AVO Software integration meeting and preparation of the January AVO demonstration. Visit of E. Kontizas, Strasbourg 10-24 November 2002. Science expertise on AVO prototype. Collaboration AVO-VO India, Pune 17-25 November 2002. Collaboration with Indian VO on VOPlot. (See EU approval email Annex A1) Discussion and preparation of the AVO Demonstration, Cambridge 08-10 December 2002. AVO Technical Meeting, Cambridge 14-17 December 2002. Preparation of the AVO demonstration in January 2003. . AVO Meeting with EC IST Directorate General. Brussels 14 January 2003 AVO Demonstration Presentation of the AVO software prototype. Manchester, 19-22 January. IVOA: Data Modelling Workshop, ESO Garching 23-24 January 2003. AVO Executive Meeting, ESO Garching 03-04 March 2003. Collaboration AVO-VO India, Pune 08-17 March 2003. Collaboration with Indian VO on VOPlot. (See EU approval email Annex A2) IVOA: Registry Meeting, London 19-20 March 2003. AVO discussion, Munich 09-12 April 2003. Interoperability Meeting, Cambridge 11-16 May 2003. GRID Astronomy Meeting, Edinburgh 29 June-3 July 2003. Virtual Observatory as a Data Grid. Collaboration with Work Area 3. IVOA Meeting, AVO Demonstration, International Astronomical Union General Assembly, Sydney 13-28 July 2003. (See EU approval email Annex A3) Participant 5: CNRS / IAP AVO Workshop Definition of the Terapix/AVO Processing Cluster (hardware and networking). Garching 14-18 October 2002 (Please Note: Travel occurred in 1st recording period, however invoiced in 2nd reporting period) AVO Workshop Demonstration and validation of the Terapix/AVO Processing cluster. (see ( HYPERLINK "http://terapix.iap.fr/rubrique.php?id_rubrique=47" http://terapix.iap.fr/rubrique.php?id_rubrique=47) Garching, 18-22 November 2003 Preparation of the AVO demo for January 2003. Garching, 2-6 December 2002. AVO Workshop. Garching, 10-19 February 2003 AVO Demonstration Presentation of the AVO software prototype. Manchester, 19-22 January 2003. Avo Meeting discussion of links between the Terapix Astrometric pipeline and the ESO / CDS astrometric catalogues. Garching, 17-21 March 2003 Installation / Demonstration of the links between the Terapix Astrometric pipeline and the ESO / CDS astrometric catalogues. Garching, 21-25 April 2003 Meeting to discuss the specifications for the Terapix Votables. Garching, 19-23 May 2003 AVO Interoperability Meeting - Definition of standards for electronic transfer of each partner data set. Cambridge, 12-17 May 2003 First demonstrations of the Terapix output Votables. Garching 23-27 June 2003 Preparation of the Terapix poster for the ADASS Meeting. Garching, 21+25 July 2003 Meeting validation of the Terapix Votables. Garching, 18-21 August 2003 AVO Workshop following the ADASS conference details of software standards for a worldwide virtual observatory infrastructure. Strasbourg, 11-17 October 2003. Participant 6: JBO VO talk given at SKA Workshop. Oxford, 7 November 2002 Astrogrid Meeting. Workgroup leaders + technical meeting. Cambridge 13 November 2002 AVO Technical Meeting. AVO Software integration meeting and preparation of the January AVO demonstration. Strasbourg 15 November 2002 Astrogrid Meeting. Discussion of VO usage and science drivers. Leicester, 21-22 November 2002 AVO Meeting. Preparation for Jan 2003 Demo. Cambridge, 10 December 2002 AVO team meeting. Cambridge 16 December 2002 Astrogrid Meeting. Technical Support Panel meeting. Leicester, 6 January 2003 AVO Meeting with EC IST Directorate General. Brussels 14 January 2003 Astrogrid Registry meeting. Leicester, 19 February 2003 Astrogrid Meeting. Ontology tutorial for AstroGrid and others, (Computer Science). Manchester, 26 February 2003 Astrogrid Meeting - Technical Support Panel meeting. Leicester, 27 February 2003 Astrogrid Meeting - Component integration meeting. Leicester, 17 March 2003 IVOA Meeting. - Registry interoperability international meeting. London, 19 March 2003 EVN Archive liaison meeting. Dwingeloo, 28 March 2003 Astrogrid Meeting - Focus meetings and Technical Support Panel meeting. Leicester, 14-15 April 2003 IVOA Meeting - Workgroups on IVOA standards and interoperability. Cambridge, 12-16 May 2003 Astrogrid Meeting - AstroGrid Technical Support Group Leicester, 6 June 2003 ADASS Meeting and subsequent AVO meeting. Strasbourg, 12-25 October 2003 5.2 Manpower allocation and utilization The following section details the planned and actual allocation of human resources to different work areas from the six partner organizations of AVO. Annex 1 of the contract (DESCRIPTION OF WORK) contains the detailed planned distribution of manpower for each work area and by institution. Those planning numbers for the entire duration of the project are summarized in the following tables compared with the actual numbers for year 2 and the submitted cost statements for manpower. Work AreaANNEX 1 (person months)Actual Year 2 (person months)Work Area O35.818.7Work Area 1138.89.8Work Area 222083.5Work Area 317830.0TOTALS572.6142 In the following table the person hours listed in the cost statements (column 4) are exactly equivalent to the reported person months for year 1 (column 3) when each organizations FTE accounting procedures are taken into account. ContractorANNEX 1 (person months)Actual Year 2 (person months)Cost statements Year 2 (person hours)Cost statements Year 2 Coordination (person hours) 1. ESO.DMD115.245.759285162. ST-ECF68.715.521873. UEDIN.IA144.014.220074. CNRS.CDS.OAS/ ULPS.CDS.OAS108.034.248315. CNRS.IAP64.720.729146. UMNC.DP.A.JBO*72.011.71650Overall Total572.6 =SUM(ABOVE) 14219517516* UMNC.DP.A.JBO cost statements only list EC funded staff. 5.3 Project Budgets The budgetary details for each AVO partner is presented as Cost Statement Summary forms contained in Appendix C. The following table summarizes the expenditure in Euros for the major cost categories. ContractorsPersonnelDurable Equipment Travel and subsistenceConsumablesCoordinationTotalESO.DMD157,83913,6500017,750189,240STECF72,084016,397088,481UEDIN.IA65,5131,1445,64872,305CNRS.CDS.OAS/ ULPS.CDS.OAS143,150021,3160164,466CNRS.IAP68,5456,9818,28283,808UMNC.DP.A.JBO41,1752,7986,15850,131Year 2 TOTAL548,30524,57357,801017,750648,427Planned TOTAL whole project2,017,967252,100154,900024,1502,449117 5.4 Attribution of tasks The specific attribution of costs for posts is covered by the identification of work areas in the table from Section 5.1 and the individual work area reports contained in Section 2 together with details contained in the Cost Statements for each partner. 6 Appendices Appendix A1 Travel Authorization 1   Appendix A2 Travel Authorization 2   Appendix A3 Travel Authorization 3   Appendix B1 DMBS Technology for the AVO Clive Page, University of Leicester 2004 January 14 Abstract Database management technology is central to the development of the Virtual Observatory (VObs), since its eventual aim is that the worlds astronomical data collections should look like a single large distributed database. Relational database management systems (DBMS) are good at searching through large tabular datasets such as source catalogues, but the important operation of cross-matching sources in different catalogues is supported only with difficulty. Two algorithms for doing this were examined: that based on a true spatial index was found to be superior. Since relational DBMS are not all that well suited to the requirements of the Vobs, some alternative structures were also examined. An object-relational open-source package, PostgreSQL, appeared to be the most suitable of the DBMS examined. 1. Introduction The principal aims of the Virtual Observatory (VObs) are to make the world's collection of astronomical data archives uniformly accessible, and to make it easy for astronomers to explore and mine these large data collections for new information. Database technology obviously has a vital role in building the Virtual Observatory, indeed the eventual objective is that the VObs should appear to be one huge, distributed, database. This report describes activities under AVO work area 3.3 up to the end of 2003. Much of this was carried out as part of the AstroGrid project, which has database needs very similar to those of the AVO. Some related activities in other work areas are also described briefly to put the work into context, for example progress on standards for database queries and results. Astronomical data centres contain data in many different formats, for example: images, spectra, time-series, complex visibilities (in radio astronomy), photon-event lists (at high energies), and source catalogues. Images and most of the other forms of data require specialised data processing software, so the role of the database management system (DBMS) is essentially just that of keeping track of each dataset and providing search facilities based on the associated metadata. A modern DBMS can store images and similar datasets within a record as a binary large object (BLOB), but one cannot do much with a BLOB except import it or export it on demand. In practice most astronomical archives keep images and similar datasets as external files, with the DBMS just storing the metadata and a link to each file via its path or URL. In either case such use of database technology is fairly straight-forward and presents no problems worth further discussion. There is one very important exception to this: the data product resulting from astronomical data analysis is often a list of objects detected in some region of the sky, usually known as a source catalogue. These are simple tabular datasets, much like the tables which relational DBMS are designed to process. Source catalogues vary in size from tens to billions of rows and from a few columns to a few hundred. Many of the operations needed by astronomers are similar to ones which RDBMS support, for example joining one catalogue with another. It is only in recent years, however, that DBMS have become powerful and cheap enough to store and process actual scientific data, rather than just the metadata, but experience in using them in this way is still in its infancy. Although relational DBMS are very powerful and stable packages, they are designed for use in commerce; their use in scientific research is not entirely problem-free. This document describes the main areas in which problems arise, and reports on the progress in solving them. 2. Scientific Requirements In order to make a start on developing the VObs infrastructure, the AstroGrid project adopted the Unified Process for its software development; this depends heavily on use-cases. The first step was to collect a range of research problems which could make good use of the facilities of the eventual VObs. From this rather large set ten representative problems were selected for detailed analysis. This set of ten, however, included four problems in the field of solar physics or solar-terrestrial physics, leaving only six relevant to the AVO. Full details of the "top ten" are given in [1]. An outline, concentrating on database requirements, is given here: Brown Dwarf Selection: these may be found by looking for stars which are faint, red, and have high proper motions. The information required appears partly in astrometric catalogues and partly in deep optical or infra-red catalogues such as 2MASS, APMCAT, and SDSS (with WFCAM and VISTA in future). This requires extensive cross-matching between large catalogues, and then selections on complex criteria. The detection of high proper-motion objects may also require cross-matching catalogues of positions measured at different epochs to find sources which have moved. The science case notes that the necessary datasets are often located at different sites. Deep Field Surveys: the analysis depends large on extraction of source lists from images, but also needs a cross-matching facility. The source catalogues involved are likely to be of modest size, since they arise from small areas of sky such as the Hubble Deep Field. Galaxy Clustering: the general procedure is to use multicolour optical survey data sets (such as DPOSS), and from there select sources marked as galaxies which have particular properties, e.g. are in a particular locus of the (g-r) vs (i-r) colour space. Then one creates density maps. High Redshift Quasars: searches will require comparison of optical (i, z bands) and near-IR data over thousands of square degrees; current work uses SDSS results, in future WFCAM and VISTA catalogues will be used. Radio and X-ray surveys may also be used to select hi-z quasars. This certainly requires scanning large catalogues using complex selection criteria, and is likely to involve cross-matching between catalogues from different wavebands. Low Surface-brightness Galaxy Discovery: this requires extensive image-processing which is outside the scope of this document, but the initial step is tosearch in large catalogues such as 2MASS for all objects with non-thermal colours. The science case also notes that Radio data (e.g. Arecibo HI 21cm) can also be used: radio selected LSB's are compared with optically selected sets. Supernova-Galaxy Environment: the main activities in this science case involve searching archives for relevant image and spectroscopic data, but some database work is involved e.g. in cross-referencing the position of a SNR candidate with other objects in the vicinity such as galaxies or clusters of them with known red-shifts. Besides solving specific problems such as these, the VObs must have various more general capabilities. Firstly, we must cope with the astronomical data explosion: the volume of data collected by observatories seems to be increasing at an exponential rate, especially because of the availability of ever larger and faster electronic photon-detectors: the consequences of this are outlined in section 3. As more datasets from more observatories come on-line, it becomes more difficult to find all the right data to solve a given research problem, and even experts are likely find a resource location service useful. All the VObs projects now seem agreed that some form of resource registry is needed: this is of course a form of database, and is briefly covered in section 4. Many research programmes, including most of those listed above, depend on making use of data from several different sites. It is vital therefore that the VObs adopts standards for queries and results, so that data can be interchanged or combined readily. Good progress has been made in this area, as noted in section 5. Several of the scientific problems listed above depend upon cross-matching source catalogues: algorithms for doing this on large datasets held within a DBMS have been developed under the AVO programme, and are covered further in section 6. Data exploration and data mining facilities are important but we need to determine to what extent these can be carried out within a DBMS. If not the data will have to be exported to external packages, as explained in section 7. Database packages are designed to access data held on local discs, but VObs users will want to access data held on many remote sites: the problems of providing distributed database facilities are outlined in section 8. Finally, it is clear that many new astronomical data centres will be coming on-line over the next few years, some large, some small. Many existing sites are also using rather basic DBMS which cannot support all the functionality desirable in the virtual observatory. We therefore carried out an assessment of various database technologies, and a more detailed evaluation of a number of the more suitable DBMS packages. Some alternatives to relational DBMS are examined in section 9, and results of our evaluations are reported in section 10 and in the Appendix. 3. The Astronomical Data Explosion The VObs must be capable of handling the "data explosion" (otherwise known as the data avalanche or data tsunami, choose your metaphor) faced by astronomers. Moore's Law suggests that computer power and storage capacity double about every 18 months; this seems to have been true for over two decades, and seems likely to continue for at least another few years. Astronomers gain benefit from Moore's Law by using ever larger and faster CCD detectors in their telescopes, so that volumes of raw data have been expanding at much the same rate as processing capacity. Derived data such as source catalogues are growing in proportion, or perhaps more rapidly, as large systematic sky surveys are occupying a higher proportion of telescope time. The longest source catalogue at present, USNO-B, has over a billion rows, but several others are nearly as large. It is not uncommon for these tables to be vary wide as well: the widest encountered so far, 1XMM, has around 400 columns. We know, however, that instruments coming on stream over the next few years (WFCAM, VISTA, e-MERLIN, ALMA) will produce much larger volumes of data than those in use at present. Fortunately, relational DBMS seem to able to handle tables of this size, if enough money is spent on the hardware. A recent survey by by WinterCorp [2] showed that the largest known table in the commercial world had around 250 billion rows and occupied some 10 TB of disc space; secret applications may, for all we know, be even larger. This is around two orders of magnitude larger than the biggest astronomical tables in current use. We obviously need to develop systems and algorithms which are capable of being scaled up to appropriate levels. Telecommunications costs, unfortunately, have not been falling as rapidly, and network bandwidth available to us has not kept up with the growth in data volumes. Currently the largest source catalogues occupy around 100 GB of disc: transporting such datasets over national networks takes a few hours; over international links somewhat longer. If current trends continue, so these catalogues grow with Moore's Law but network bandwidth grows more slowly, it will get increasingly difficult to transport such datasets over the Internet. Another factor to note is that some database operations, including joins, require frequent interactions between servers, so they demand a network with low latency. Here the speed of light presents a insurmountable barrier. Because of high telecommunications costs data from mountain-top observatories are being routinely shipped back on tapes or hard discs. The option of carrying out at least the earlier stages of data reduction at the observatory and just shipping back the reduced data is also looking attractive: for those who actually need the raw or semi-processed data, the observatory will become another data centre. 3.1 Grid Computing The Grid Computing model is currently fashionable, but different models suit different problems. Indeed it is now clear that there are at least three types of grid: Computational Grid: this provides remote processing power for big compute-intensive problems. Data Grid: this allows data resources to be accessed all over the network. This corresponds quite well to what the VObs is trying to do, but we need to bear in mind the network bottleneck. Service Grid: this provides specialised services on particular network nodes, which can be accessed from anywhere. There may be some use for this in the VObs if we need to install costly licensed software on just a few nodes, but allow remote access. As noted by Jim Gray in his paper on Distributed Computing Economics [3], with current prices of processing power and bandwidth, a computing grid only makes sense for problems where one needs to crunch at least 100,000 instructions per byte. In astronomy a few theoretical studies and simulations may reach this level, but it is far above that of most data reduction and analysis programs. The computational grid model therefore seems mostly irrelevant for the VObs. The data grid model, however, is very close to that of the Virtual Observatory. In the UK the OGSA-DAI Project is trying to make data grids more of a reality by integrating database access within the grid computing paradigm. AstroGrid has installed the OGSA-DAI software on nodes in Cambridge and Leicester, and will shortly be testing the facilities available and their performance in practice. It uses JDBC to access the DBMS, and has so far been tested on MySQL, Postgres, and DB2. For more information see the report on Grid Technology from Guy Rixon. 3.2 Data Centres Data Centres cover a wide range in size: there are a few large ones (such as CDS), a somewhat larger number of medium-sized ones often with specialist holdings (for example LEDAS in Leicester), and even more small centres, many of them with rather limited facilities on the web. Not many centres have more than a few terabytes of data on-line at present, even though such storage can be purchased for just a few thousand Euro. Processing power is also cheap, as shown by the fact that most of our computers are idle for most of the time. The most scarce resources are bandwidth (as noted above) and the manpower needed to set up the databases and web-sites, and to manage the systems properly. I expect that as well as an expansion of the established data centres, there are likely to be more of them, mostly at the lower end of the size range. Some, as noted above, will be specialised centres at observatories, others will arise from new observatories or space missions. In addition it is notable that large sensitive CCD chips are now quite cheap, and useful work can be done by telescopes of fairly modest cost. There has also been a rise in the number of sky survey projects and of remotely operated observatories. Current examples include projects such as SuperWASP, the Faulkes Telescopes, and the Liverpool Robotic Telescopes. It is also becoming clear that a wealth of new short time-scale phenomena can be found by surveying large areas of the sky at frequent intervals; even amateur sky-watch programmes are producing valuable results and are starting to set up web sites. The Virtual Observatory needs to accommodate them all. The smaller data centres are likely to have quite modest funding, and given the very high prices charged for the main commercial DBMS, it seems clear that the VObs ought to choose free or very inexpensive products if at all possible. Of these only Open Source packages give one the assurance that they will always be free. Fortunately most of the world's VObs projects appear to have a bias in favour of Open Source software; database management packages may be an exception even though they are some of the most expensive software packages on the market. The larger data centres often use an expensive commercial DBMS, but many data centre managers have told me that their choice of DBMS was strongly influenced by what was already licenced at their site (because it was used for teaching or administration). There seem to be very few cases in which a particular commercial DBMS has been chosen on scientific grounds. 3.3 Architectural Implications The obvious answer to the bandwidth bottleneck is to site the processing power next to the data storage facilities: the mantra has been "ship the results, not the data", since the results are usually much smaller in volume. Remote processing of data will require a new model for managing data archive centres, which up to now have been designed just for simple searches and modest data retrievals. To provide a full range of facilities, the VObs will need to encourage data centres to provide: Significant processing power so that more complex searches, selections, and joins can be performed in situ. Ample disc store for the temporary of intermediate results. Appropriate software to run on their data holdings, for example a suitable DBMS with perhaps statistical and graphical packages. The necessary authentication and authorization infrastructure so that external users can be let loose on the system without risk. What this requires, obviously, is that the software to perform the processing be present at each site where large datasets are located. Many of the larger data archive sites will already be using DBMS, and it may well be feasible to provide additional middleware to support the main functionality of the VObs on top of these DBMS. But a significant proportion of important astronomical data are located at smaller sites, where there may be no suitable DBMS in place, and the funding situation may not allow them to purchase an expensive commercial product. The use of cheap or free software will obviously make it possible for a much wider range of data archives to participate fully in the VObs, and thus enhance the value of the system as a whole. There are at least three Open Source relational DBMS, some commercial DBMS are also free for academic or non-profit use: for example Sybase ASE has a Linux version which can be downloaded free; IBM's DB2 is free to all academic users (including research institutes, apparently) in most countries, under the IBM Scholars' Program; and quite cheap academic licences may be obtained for Microsoft's SQL Server. There are good reasons for the VObs to be based on Open Source software apart from the cost arguments: open source software avoids all the complexity and time that normally has to be spent on licence issues, and it essentially reduces the risk that the product will die or be taken off the marked. As the story of O2 (see section 9.2 below) shows, this can be a serious risk. 4. Resource Registry The need for a resource registry arose originally from a realisation that even the expert user cannot know the location of all the useful sources of astronomical data on the network. The registry of astronomical metadata is now an accepted part of the VObs infrastructure, and it is pleasing to report that all the VObs projects have agreed on its basic properties. There is likely to be at least one registry per VObs project, though perhaps with differing levels of detailed information. These registries will have a number of special properties: they will update their contents from one another, perhaps once a day, it is also likely that they will eventually be able to harvest their information from data archive sites automatically, much in the way that search-engine robots do. The protocols for data retrieval and harvesting are the subject of discussion, but it is likely that agreement will be reached soon. The registry is, therefore, a rather specialised type of database, but the total volume of data is rather small, perhaps only a few megabytes. The exact functionality of the registry is still being defined but it seems likely that the search criteria will be fairly simple, and given the small data volume. The requirements can probably be satisfied with a basic relational DBMS, or an XML-DBMS, since much of the data input and output will be in the form of XML documents. It seems unlikely that the registry will present any specialised database challenges, but the AVO database team are obviously willing to give advice if required. 5. Standards for Interoperability Considerable progress has been made on standards for interoperability after a series of meetings of the International Virtual Observatory Alliance (IVOA). AVO members have been active in all the forums of discussion. There has been general agreement that the VObs should adopt the Web Services paradigm (use of SOAP messages and WSDL descriptions) and data interchange standards based on XML. This does not render current systems obsolete since WSDL supports continued use of CGI-based interfaces, including those based on the existing ad-hoc standards such as GLU and ASU, devised by CDS some years ago. 5.1 VOTable The first standard to be agreed was that for the results of a query sent to a database: the VOTable is an XML format with metadata based on the headers in the well-established FITS file format. There are three different ways of encoding tabular data within a VOTable: TABLEDATA - which is pure XML and therefore rather verbose, but fully compatible with existing XML software. BINARY - using the standard XML way of encoding binary data within a larger XML document: this is much more efficient but not easily decodable by generic XML applications. FITS - the XML file stores essentially just (a copy of) the metadata, the actual data is accessed by following a link (URL) to a separate FITS file containing a binary table. This is even more efficient, and allows existing FITS files to be enclosed in an XML wrapper. Several useful applications are already available for handling VOTable data, including TOPCAT from the UK's Starlink Project, and VOPLOT from the VObs project of India. At present only the TABLEDATA option is widely supported and tested; it will be essential to support at least one of the more efficient options if large chunks of tabular data are to be shipped from one site to another. 5.2 Query Language Agreement on a query language has taken longer to reach, but current drafts envisage that three levels of query language will be needed eventually. A draft specification for the base layer, ADQL, is now agreed, and implementations in the US and in Europe have appeared. The syntax is based on the standards for SQL92 and JDBC, with both a simple SQL-like string and an XML format defined. The next layer up will be responsible for handling syntax for higher-level functionality including cross-matches between catalogues. It seems likely that a number of further iterations will be needed before this layer can be fully defined. In the long term we need to give the remote user of a database the same facilities that local users have at present. This means allowing users to import their own datasets, export subsets that they create, to create and define their own indices, write their own user-defined functions, getting estimates of query duration (using EXPLAIN or similar), scripting sequences of queries, giving time limits to queries, and allowing run-away queries to be aborted. The need for several of these facilities has already become evident from the Skyserver system at Johns Hopkins University which allows SQL queries to the SDSS and associated datasets. Considerable further work is needed before all these facilities can be incorporated into IVOA standards. 6. Cone Searches and Catalogue Cross Matching One of the most productive ways of extracting new information from existing source catalogues is to locate the same source in two or more of them: if the catalogues arise from observations in different wavebands this gives valuable spectral information, if they were taken at different epochs it may reveal variability in flux or motion in space. The most basic such search is to perform it one source at a time: since the position is always slightly uncertain (and some objects are extended or may have moved) it is normal to search for a small circular region about the position of interest in the sky - in three dimensions this is a cone from the observer out to infinity or the edge of the visible universe, whichever comes first. More generally one will want to cross-match all the sources in one catalogue with the corresponding sources in another: in database terms this is a join between tables, but a special type of join, because an overlap of spatial error regions is the match criterion. 6.1 Cone Search Cone-searches are supported by quite a number of astronomical data archive sites, and are popular with users, although perhaps the fact that they are just about all that only search facility provided by most sites has some influence. It is notable that cone searches are not mentioned explicitly in any of the top six science problems analysed above, This is probably because it is a rather basic facility, often used in small investigations, whereas these science problems describe much larger programmes of work designed by experienced astronomers. The names and units used by the various on-line cone searches vary considerably, but there have been two attempts to bring some order to the chaos. The Astronomical Server URL (ASU) was defined nearly 10 years ago by CDS; more recently the US-NVO has defined a specification for a simple cone search, which is, for reasons unknown to me, quite different in detail. The GLU/AstroGLU system, also defined by CDS, is used at a number of sites to transform a single cone search query into the actual set of CGI parameters required by a number of well-known sites. A few web sites have extended their cone-search to allow the user to upload a list of positions of interest and then perform a separate cone search on each one. The results, however, are generally left as a set of separate tables; it is a non-trivial problem to merge meaningfully results coming from different catalogues: this is a subject of current study by Patricio Ortiz of AstroGrid. It is perhaps best to see the cone-search as a special case of a spatial join, when the first input catalogue consists of just one position. Any system which supports a spatial join can perform a cone-search efficiently, but not vice-versa, because simple search methods do not scale up adequately. Many current cone-search services are based on WCSTOOLS (described below in section 9.1) which essentially rely on a one-dimensional index of the sky (or a crude slicing along one axis, and an index or sequence of values along the other axis). This works well enough for small tables and small areas of sky, but is inherently un-scalable. This is shown in the following table of results, obtained on the whole 2MASS catalogue of 470,992,970 rows and 60 columns, ingested into Postgres. Cone searches covering an area of 0.01 and 2.0 square degrees were carried out, when the table was accessed by either a B-tree on declination, or an R-tree on both RA and declination. The elapsed times are in seconds.  HYPERLINK "http://wiki.astrogrid.org/bin/view/Astrogrid/DataFederationandDataMining?sortcol=0&table=1&up=0" \l "sorted_table" \o "Sort by this column" Indexing method for cone search  HYPERLINK "http://wiki.astrogrid.org/bin/view/Astrogrid/DataFederationandDataMining?sortcol=1&table=1&up=0" \l "sorted_table" \o "Sort by this column" 0.01 square degs  HYPERLINK "http://wiki.astrogrid.org/bin/view/Astrogrid/DataFederationandDataMining?sortcol=2&table=1&up=0" \l "sorted_table" \o "Sort by this column" 2.0 square degrees Declination index, B-tree 156.7 secs 1639.7 secs RA+declination index, R-tree 1.2 secs 2.2 secs The superiority of the R-tree is overwhelming on a table of this size. The R-tree access times reduce further, to a millisecond or so, when the same (or a similar) query is repeated, as the required index blocks are cached in memory, whereas repeated B-tree accesses require scanning rather a substantial fraction of the original dataset, and these hardly speed up at all. 6.2 Cross-Matching The main criterion for matching celestial sources in two or more catalogues is normally the coincidence of celestial positions, usually expressed as a pair of spherical-polar coordinates (right ascension, declination). In practice, of course, these positions are always somewhat uncertain, and the match condition actually needs to be the overlap of the respective error regions. These regions are often circular, but some may be elliptical or more complicated in shape. The draft plan for the demonstration AVO Geometric cross-matching facility appears to suggest that only the nearest neighbour should be selected in each case, but this is hard to justify scientifically: there may be no nearest neighbour within the error-region if the source has no counterpart, or there may be several, and the next nearest may be only slightly farther away but be a better match on other grounds. Where there are several matching sources in the second catalogue then other properties of the sources may have to be used to find the actual counterpart, such as spectral type or magnitude, but this is a matter for scientific judgement and can be carried out after the list of apparent matches has been produced by the database. The basic cross-matching operation is what in database terms is called a JOIN, and RDBMS are highly optimised to perform joins between tables. There are, however, a number of complications which the design of the cross-matching software needs to take into account: Most RDBMS are designed to perform efficiently only an equi-join, i.e. one where there is an exact match between two integers or strings and cannot use an index when floating-point numbers are compared within error limits. In some catalogues all error regions will be the same, in others it will depend on other columns in the table, such as an error-radius, which further complicates the join. One cannot use a simple cartesian distance for coordinates on the spherical surface of the sky, but the great-circle distance (and the simplest formula lacks accuracy when small angles are involved, the haversine formula is much better). Spherical-polar coordinate systems have problems with wrap-around of right ascension at zero hours, and singularities at the poles. Catalogues may have positions measured using different equinoxes (B1950 or J2000 for example): if so precession needs to be applied to one of them before coordinates can be compared. Nearby sources may have significant proper motions, so an increased matching distance may be needed for catalogues corresponding to widely different epochs. It is sometimes of great scientific interest to know whether a source in one catalogue has no counterpart in another: this corresponds to a LEFT OUTER JOIN in database terms. These obstacles have led many previous astronomical projects (such as ROSAT and XMM-Newton) to write procedural code, in C or Fortran, to perform their cross-matching. 6.3 Spatial Join Algorithms There are two algorithms known to be suitable for performing a spatial join using a relational DBMS: Join using a spatial index (such as an R-trees) which is available with some DBMS. The pixel-code algorithm, described more fully in [4] The idea of the pixel-code algorithm is to cover the sky with a grid of pixels, numbered with integers, and build a standard B-tree index on this set of integers. A simple grid along lines of right ascension and declination is not very satisfactory as the pixel areas vary down to near zero at the poles. Astronomers have developed a number of roughly equal-area pixelations of the sky, including HTM (from Johns Hopkins University), HEALPix (from ESO), and Qbox (from CDS) and all of these solve the problem well. But whatever grid is chosen some error regions are bound to overlap two or more pixels, so a simple equijoin of pixel numbers will lose information. The pixel-code algorithm solves this problem but requires additional tables, and two simple equi-joins and one three-way join. Its great advantage is that can be used with even the most basic relational DBMS, since it needs only simple B-tree indices on the various tables. But it has some drawbacks. Firstly it is substantially more complicated. Secondly the final selection requires a SELECT DISTINCT operation to remove duplicates; this implicitly involves sorting the output table, which is an operation which does not scale linearly with table size. Thirdly it is more difficult to change the match criterion, say from two sigma to three sigma, than with an R-tree index. Because of the doubts about speed and scalability, the two algorithms were compared on some datasets of increasing size. These tests compared a spatial join between a section of the 2MASS catalogue with the corresponding area of USNO-B using both the pixel-code algorithm and the R-tree indexing. Because Postgres had the best R-tree indexing, it was used for both algorithms. The comparison was used on a number of areas of sky of increasing size. Sky area (sq.degs)Pixel-code (secs)R-tree (secs)368854108406161324115055397246231964It is clear that the R-tree join is faster than the pixel-code method, and that the speed advantage increases with dataset size. Since the R-tree join is also simpler, more scalable, and more flexible, it seems better on all grounds. 7. Data Exploration and Data Mining The term "data mining" is usually defined as the search for useful information hidden in large datasets. In the commercial world data mining generally takes place in the data warehouse: a large static collection of tables, often a snapshot of the highly dynamic transaction-oriented databases used to run the company. The data types are nearly all enumerable types such as integers and character strings. Floating-point numbers are rare: money is best represented in fixed point form as this avoids embarrassing problems with rounding errors. It is notable that Oracle, the market leader in DBMS, did not have any support for floating-point data types until quite recently; all numbers were stored as strings of decimal digits. A simple data mining query might be to find out whether a particular special offer has generated increased profits, for example by comparing before and after sales figures, or comparing sales from different areas of the country. The most common operations seem to be summation, grouping and sorting, but some packages support more advance operations include clustering, classification, regression analysis and outlier detection. The last of these is used, for example, to identify fraudulent use of a credit card. 7.1 Data Mining Packages Some of the operations supported by data mining packages are potentially useful in astronomical data analysis, so several of them were examined briefly. Nearly all of those examined were designed for what, in our terms, are very small datasets, and the examples of usage rarely used more than 3000 rows. One package was said to be capable of handling "very substantial" datasets when this meant 100,000 rows. Such limits arise, I think, from holding data entirely in memory; many packages were also interfaced to spreadsheets such as Excel, which have their own limits. Most packages were rather specialised, so that a number of them, all with very different data formats and user interfaces, would be needed to get a reasonable range of functionality. In summary: none of those examined so far seemed a good match to typical astronomical requirements. On the other hand there is a wide range of products on the market, and some astronomical datasets are fairly modest in size. Most packages were rather expensive, but the cost might be acceptable if it were possible to use the service grid model to mount the package on a single computer which could be used by anyone in the VObs community. Of course we do not really know how to do this yet, and the package licence might not permit such use. Despite these reservation, I think that a more serious evaluation of some of these products for astronomical use would be worth while. What astronomers need rather more, I think, is what is perhaps better described as a data exploration facility: after all one has to explore the data for nuggets or even rich seams of ore before any mining can be considered. 7.2 Data Exploration Support for interactive data exploration is essential, as users are unlikely to get their queries right first time. They will want to try an initial selection, and then examine the results, perhaps by browsing through the first or last rows on the screen, or computing simple statistics on them (range, mean, etc.), perhaps sorting them in order so that the extreme values can be inspected, or perhaps displaying the results in some simple graphical format. When the first selection stage seems satisfactory, the astronomer goes on to perform further database operations on the intermediate results. If the input dataset is large, so that sequential scan operations are slow, it may be desirable to select a representative subset randomly. Although this incremental or iterative method of working will be familiar to all those who have performed astronomical data analysis, it is seems alien to the database world. This and other difficulties are discussed further below. 7.3 Problem Areas The relational DBMS and the SQL language have come to dominate the commercial database market, but those doing scientific data reduction and analysis have rather different needs. Some of the obvious problem areas are analysed below, with suggested workarounds or solutions. Metadata are routinely attached to astronomical tables and their columns: the careful storage and propagation of metadata is what makes FITS files so useful and popular: columns come complete with physical units, formats for display, and free-text comments; a table can have almost any amount of additional metadata attached, applying to the table as a whole. The relational DBMS usually supports none of this, not even essential attributes like the physical units of columns. It is possible for the programmer to create additional tables to hold metadata, but this is hardly a solution as the common DBMS operations such as selection, projection, and joining will not make use of them or propagate them. Normalisation: Relational operations only produce valid results if all tables are normalised according to the rules of Codd and Date (this involves basically the removal of all duplicate information and ensuring that nothing depends on the order of rows or columns). Source catalogues and other astronomical tables may look like relational tables but they are rarely normalised, except perhaps by accident. The complex collections of data generated by telescopes tend to contain one-to-many and many-to-many relationships which can be converted into a set of properly normalised tables only after a lot of manipulation using entity-relationship modelling. Although in theory the lack of normalisation can result in incorrect results from certain sequences of relational operations, in practice this is not a problem likely to affect astronomical database use very often. Data types: All RDBMS are designed for commerce where nearly all fields are simple integers or character strings; floating-point data types, bytes, bit-strings, and data structures tend to be poorly supported. It is usually hard to display floating-point numbers in sensible formats, and reading or writing angles in sexagesimal format requires appropriate user-defined functions to be created. Storage order: Astronomical tables, especially source lists, tend to have many columns (up to 400 in a few cases): the normal storage order is row-major, which means the entire table has to be scanned even if a selection is made using the properties of just a few columns. This means that sequential performance can be relatively poor. Mathematical functions: VObs users will often want to use functions such as LOG or TAN in selections. The SQL92 Standard specifies very few of these functions, although in practice most DBMS support a reasonable range. Unfortunately the names are far from standardised, thus LOG may mean take a logarithm to base e or base 10, depending on the product. To fill in the gaps it is essential for a DBMS to support the definition and use of user-defined functions (UDFs). We are likely to want to define additional UDFs for functions needed in astronomy such as great-circle distance between points. Null values representing missing information occur in most astronomical tables. The SQL Standard supports the necessary 3-valued logic (true/false/unknown) but the way in which null values are handled when sorting a column, or creating an index is not standardised. Multi-dimensional indexing is built in to very few products; several more have it as an add-on feature, often at extra cost. SQL is a non-procedural language, that is the user specifies the result needed, and the query analyser and optimiser do the rest. This is all very well in theory, but practice is often different. All DBMS expect you to create the indices you need to speed up your queries, and nearly all provide an EXPLAIN command which (though the details vary) will tell you how a given query will be executed. The requirements of exploratory data analysis, as noted in the previous section, depend on being able to execute a complex sequence of operations one step at a time, if necessary, so that you want to be able to select into some temporary table. SQL makes this difficult. There is no standard way, for example, of sending the output from one query into a new table, it is expected that all you even need from a query is plain text sent to your terminal. In practice most DBMS will allow you to select into another table, but it usually involves non-standard syntax, such as SELECT INTO or perhaps CREATE TABLE ... SELECT, or it may require two separate SQL statements. Statistical facilities are very basic in SQL: the functions min, max, mean are always provided, but standard-deviation or variance are non-standard. The calculation of a median or any other quantile is possible, but complicated. To compute more advanced statistics it is usually necessary to export the data from the DBMS and ingest them into another package. This is likely to have to use a simple CSV format, in which all column names get lost. Graphical facilities are absent (though one can just about construct a simple bar graph in SQL, that is about the limit). If any plotting or visualisation facilities are needed, the data again have to be exported and then imported into some other package. Packages designed for the VObs such as VOPlot and TOPCAT can import VOTable files, which preserve metadata, but without additional software, normal DBMS cannot produce them. These problems all have solutions or workarounds, but they go some way to explain the fact that astronomers, and indeed scientists in general, have not been keen users of database technology. 8. Distributed Databases 8.1 Distributed Join Up to now we have examined the case of the spatial join when both tables are resident within the same database. In practice the two catalogues to be cross-matched may be located at different data archive sites. How to proceed? The short answer is: copy the smaller one to the site containing the larger one using FTP or similar. A longer analysis is given below. If it is important to identify unmatched sources in the first table, i.e. to perform a LEFT OUTER JOIN, then every row in table 1 is used in producing the output table; if all of its columns are also needed in the output, then it is surely simpler and faster to copy the entire table to the location of table 2 before performing the join within the DBMS. If it is a very wide table, and only a few columns are needed in the output, in principle it might be sufficient to project a new table with just the required columns and copy this across. If, however, we are not interested in unmatched sources, so want an INNER JOIN, there might be a way of passing a smaller quantity of information across the link: we could project a new table with just the positional information (ra, dec, error-radius) say, and first check whether there is any match in table 2: if there is then any other columns of table 1 have to be transferred, but if the proportion of matches is small, then this would be cheaper. Since any join operation requires a lot of information passing to and fro, it is not just the bandwidth of a link but also the latency. These time delays may be a serious problem on wide-area links, and are fundamentally limited by the speed of light. Another question arises: even if it is inefficient, can a distributed join actually be performed using current DBMS? Some mainframe products such as DB2 and Oracle have optional support for distributed databases, but as far as I can ascertain, these are intended for use over local area networks, not long distance lines. When I have asked database experts from these companies, they say that it might be possible, but would not be very practical. One serious problem is that the connections between client and server require a number of IP ports to be open: these requirements are not at all well documented, and I suspect that there might be serious firewall problems in practice. The Postgres DBMS has a limited ability to connect to more than one server, using a contributed package called dblink. This was very easy to set up and use, and I managed to write a script to join one table with another over our local area network. A spatial join between two small catalogues which took 8 seconds when done within one DBMS, took about 60 seconds when carried out over the local area network (100 Mb/s Ethernet). This was partly because it could only make limited use of the join functionality of the DBMS, as it was essentially a sequence of unrelated cone searches. Nevertheless it is interesting that it was possible. Postgres documentation suggested that only one port needed to be open in the firewalls, and a search of the source code (not possible with commercial products) suggested that no other port was indeed required. I have now got the necessary ports opened on request between Leicester and Cambridge, and plan to test a wide-area join shortly. There is another interesting development: the Distributed Query Processing (DQP) project of OGSA-DAI has been set up to handle distributed joins over the wide area network. At present it requires queries to be specified in OQL not SQL, and cannot handle spatial joins at all, but development is continuing and we are keeping in touch with the group involved. 8.2 Data Warehouse Concept In cases in which it is not feasible to perform a join over the network, and in which there are no suitable facilities at the sites holding either of the tables that one wants to join, the best alternative is, surely, to copy both of them to some third location where the necessary disc space, software, and cpu power is available. This is the idea behind the Astronomical Data Warehouse. There is no reason why any data centre should not provide ADW facilities, but not all of them may choose to do so. 9. Alternatives Database Structures Given the limitations of the standard relational DBMS for the handling of astronomical data, this section examines a number of other structures which are used in astronomy or other fields. 9.1 Flat File Systems WCSTools WCSTOOLS, a package from the Harvard-Smithsonian Center for Astrophysics, is used by many astronomical archive sites. This is a wonderfully pragmatic piece of software which supports access to a number of well-known source catalogues in their original distribution format (or at least an uncompressed version of this): supported formats include those of USNO, GSC-II, 2MASS, Tycho, ACT, SAO, IRAS, and PPM catalogues. Essentially the WCSTOOLS scat program has a back-end matching the schema and structure of each of these, as well as its own (even more gloriously ad-hoc) formats for textual and binary data. The only accelerated access method used in WCSTOOLS is slicing and sorting. For example 2MASS is sliced into separate files each covering a strip of declination 1.67 high, and USNO-B1.0 is sliced into strips 0.1 high. Within each strip the rows are sorted by Right Ascension. This simple structure permits fairly rapid access provided the region of interest is small. Having been written by astronomers WCSTools has good facilities for things like precession, but there are no indexing facilities. It is not designed to execute spatial joins or complex selections on large tables. BROWSE This package was designed at ESOC around 1980 to access the archives of the Exosat Observatory. Software development continued at ESTEC and later GSFC/HEASARC, and the package has been used at several sites hosting X-ray data, although it is now almost obsolete. BROWSE also relies on catalogues being sorted on one coordinate: this allows it to support cone-search and other simple selections using its own command language or a subset of SQL. One notable feature is that it has good support for exploratory data reduction: the results of a selection can be saved for future use, and there are some basic graphical display facilities. FITS-based files The layout of a FITS binary table is actually very similar to that of a DBF file (a format introduced by dBASE-II and still in use by many PC products such as Paradox), and to the internal format of the files of MySQL, except that it can hold a greater variety of metadata. The collection of FITS utilities called FTOOLS (from HEASARC) can already perform some DBMS-like operations, such as selection and sorting, and adequate FITS browsers and graphical tools now exist in the form of FV and TOPCAT. It would not require a great deal of additional software to provide read-only database access to tables stored in FITS format. It would need an SQL parser and interpreter (but one was provided in later versions of BROWSE) and B-tree and R-tree indexing (which could make use of the open-source Berkeley DB and GiST libraries), but not much more. It would be very easy to access remote FITS files, as the cFITSIO library has access via FTP and HTTP protocols built in. One great advantage of this would be that every FITS table that one could access would automatically become part of one's database: it would not be necessary to ingest it explicitly. One of the most frustrating features of regular DBMS is that every table has to be loaded, usually after converting it to some simple text format such as CSV. The data loading stage is needed because these DBMS store their limited metadata (column names, data types) internally in system tables. With a FITS-based system, these metadata are an integral part of the system, and so the import/export steps can be abolished. Access could, obviously, be extended to VOTables, but the advantages of efficient access would be lost for VOTables which used the XML TABLEDATA format, as there is no regular stride to the data values. 9.2 Object-oriented DBMS The data structures which astronomers want to store are often intrinsically hierarchical: for example the XMM-Newton results database is divided into units of observations, each consisting of several exposures, these have data from six instruments, each having a number of separate data files. Storage of such structures in a fully normalised set of relational tables is much less natural. This led the XMM Survey Science Team to consider the attractions of OO-DBMS, which support a much wider variety of data structures. Another advantage of the OO-DBMS is that connections between related items in tables can be made simply by following pointers, whereas in a relational DBMS they require explicit join operations, which are computationally intensive. The schema of an OO database can also be designed with any required collection of astronomical metadata. There are also some drawbacks to OO-DBMS: They have a very small market penetration, which means that they are expensive, and not as robust or mature as their relational equivalents. They come with a rather limited set of utilities such as graphical front-ends and software development tools. Queries use OQL, a poorly-standardised language which somewhat resembles SQL, but requires an additional learning effort. A working system requires a considerable amount of custom code to be produced, usually in an object-oriented language such as Smalltalk or C++. The schema of the database is embedded into the structure of the database, and compiled into the access code. Subsequent changes to the schema can be very disruptive, whereas the corresponding change to a relational system, adding a new table or column, would have little or no impact on a running system. L'histoire d'O2 The XMM-SSC team, led by CDS, evaluated a number of relational and OO DBMS and finally chose for project's internal use a pure object-oriented database product called O2 which was a spin-off from the French informatics institute INRIA. This had the advantage of allowing programming in a version of C called O2C, and promised easy schema modification. It was in fact a good choice on technical grounds, though we encountered a few serious bugs. Otherwise things were much less rosy. The O2 company was taken over by Unidata, which in turn became part of Ardent Software who decided to make O2 a "mature product", and promptly discontinued development. They continued to take our money for "maintenance", however, but were soon taken over by Informix, who were then purchased by IBM. This gave IBM more DBMS than they wanted, and O2 was one of those hived off into a separate company called Ascential. Maintenance, in the form of vital bug fixes, was eventually provided by a separate company called Oxymel although at a much higher price. The long-term future of the product is very uncertain, and the XMM-SSC project is seeking ways of extracting itself from the mess. The moral of the story is that reliance on a commercial product does not guarantee its future; an open-source product in this respect might have enjoyed cheaper and better support, with more of a long-term future. Objectivity/DB The Sloan Digital Sky Survey data processing system, led by Johns Hopkins University, was originally based on the use of Objectivity/DB, which they chose for similar reasons. This too was not a success: the performance was poor, they found serious bugs which were not fixed quickly enough, and had to provide their own query language parser to overcome defects in that provided. Eventually the problems became too great, and they switched to a relational DBMS instead, choosing Microsoft SQL Server. The transition seems not to have been too painful, and they claim to have experienced a very substantial performance improvement for many types of query. Further details are given in [5] and [6]. Conclusion Although object-oriented DBMS still look attractive for certain applications, they have failed to gain a significant market presence, and the VObs is not an area where they would be a sensible choice. 9.3 XML DBMS The use of XML as a glue between disparate applications makes good sense, and the VObs has taken advantage of the expected wealth of tools available for handling XML datasets by devising VOTable. A large number of "XML databases" is now on the market, but the term covers a wide range of products. Only a few are true XML database managers, others have a thin XML-speaking layer on top of a standard relational system. Efficient storage of large tables is unlikely to be one of the design aims in either case, and these do not merit further examination for the general needs of the VObs. There is one area in which an XML-DB may be useful, that is in the Resource Registry, which has to contain a relatively small amount of data, but where the structure is potentially quite complex. 9.4 Object-relational DBMS The term object-relational has no generally accepted definition, but was coined back in the 20th century when the term "object oriented" was still popular. It is generally claimed by relational DBMS which can also handle user-defined data types, i.e. data structures. Most of the leading brands such as Oracle and DB2 now claim to be fully object-related, and so is PostgreSQL, the leading open-source DBMS which was designed from the outset to be object-relational. Since astronomers sometimes do want to store simple data structures, such as arrays of data, or coordinate pairs, these are to be welcomed. 9.5 Column-oriented Storage If tables were stored with all the values in one column being contiguous it would obviously speed up selections that are not index-assisted but which only reference values of a few columns. The reason why nearly all DBMS use row-wise storage is that it is extremely expensive to perform inserts or deletes on column-oriented storage, but that is not a problem with a read-only application such as source-catalogue access. Sybase IQ The leading commercial product which does this is Sybase-IQ. This is a product of the Sybase company, and understands SQL, but is otherwise unrelated to their relational DBMS. It is designed for the commercial data warehouse market, and besides column-based storage, it implements a number of advanced indexing and data compression options. We have been involved in an informal evaluation of the product recently, led by Jim Lewis of IoA Cambridge: initial results are good for many types of query. Unfortunately there is at present no version for Linux (it was tested on Sparc/Solaris), it has no spatial data support. As one expects from a product of this type, licences are extremely expensive even with academic discounts. If it turned out that there was sufficient demand for the execution of the types of query that it accelerates so well, then perhaps there might be a case for installing it on a single node, accessible to VObs users over the network. The advantages of column-oriented storage can be realised other ways: some experiments suggest that one can obtain a useful speedup if each column in a catalogue is stored as a separate one-column table in a simple DBMS such as MySQL. Of course the SQL for all queries becomes much more complicated as a result. Given the performance advantages of column-based storage, I realised that the FITS Standard was broad enough to encompass something equally efficient: a table can be stored as a single row of a binary table, with each column being a vector of the same length (the cardinality of the original row-based table). It was easy to produce a large table in this format, together with a program to access it, using the cFITSIO library. The performance was indeed very much better for simple one or two-column selections. The test query was to find the mean and standard deviation of a single column of a table, which was a sample of 3.5 million rows of USNO-B. This was tested last year on a 450 MHz PC, so the results are not directly comparable to others reported later. DBMSTime, secondsDB29.0MySQL7.3cFITSIO - row-oriented2.0cFITSIO - column-orientated0.7There are other ways of implementing column-oriented storage in a FITS file, for example putting each column in a separate header-data unit. This would be more compatible with existing software. It would also be possible to take advantage of data compression options with each data unit holding only a single data type, which has the potential for significantly reducing the number of I/O operations. The cFITSIO library already has good support for data compression. Current DBMS do not seem to have made use of data compression, perhaps because they were designed in the days when processors were too slow to do decompression on the fly. 10. DBMS Evaluations The initial list of DBMS that we considered for evaluation is given below, with some initial assessment of their potential value in astronomy based on published documentation and in many cases discussions with users. Commercial DBMS Ingres: used at MPE and Leicester for some years; no outstanding features; no spatial indexing; poor market share. Sybase ASE: used by CDS, Leicester, CfA, and many other sites; above average feature set for scientific data, but spatial data support is in an add-on product. There is a free version for Linux (but less up-to-date and without spatial indexing). Oracle: current market leader, object-relational, very expensive list prices for licences. Used mainly at sites where a site licence is available already. Spatial indexing in an add-on product. Some missing functions in the SQL dialect, e.g. degrees, radians, pi. SQL Server: easy to install and use, but no spatial indexing, and can be run under Windows only. Informix: good spatial indexing built-in, based on R-trees, but product now owned by IBM and has an uncertain future as it competes with IBM's own DB2. DB2: IBM's heavyweight object-relational product; spatial extender based on multi-level grid files is an add-on; free for use by registered academics under the Scholars' Programme. Open Source DBMS Firebird: the open source version of Borland's Interbase, now withdrawn from the market. Reputed to be a good stable product, but no outstanding features, and no known users in astronomy. MySQL: lightweight but reputed to be fast, used by many astronomical sites; latest release has R-tree indexing built in. PostgreSQL: full-featured object-relational DBMS originally from UC Berkeley where Ingres was invented; has R-tree indexing built-in, and a growing number of enthusiasts in the astronomical world. SAP-DB: another former commercial product now released into the wild, but likely to be merged with MySQL soon. 10.1 Packages Evaluated In 2002 we selected for basic testing the following: Sybase ASE, Oracle, SQL Server, DB2, MySQL, and PostgreSQL. The results of our tests are available on the AstroGrid wiki. In 2003 we selected for further evaluation with larger datasets the two most promising open source DBMS: MySQL and PostgreSQL, and for comparison one commercial product, DB2, since it had spatial indexing available and was available free of charge. 10.2 Desirable Features Firstly we wanted to compare spatial joins using R-tree (or other spatial) indexing with the pixel-code algorithm. The results of this might determine whether a DBMS with spatial indexing was desirable or not. Secondly we wanted to evaluate the short-listed DBMS for the following (in no particular order of importance): Ease of installation and use Ease and speed of data loading and export Performance on simple selection queries Performance on spatial joins and cone-searches Suitability for scientific queries, e.g. good selection of maths functions, easy to add user-defined functions The detailed results are given in Appendix A below. 10.3 Summary The spatial join is clearly performed better by an R-tree index than the pixel-code method; it has the advantages of speed, simplicity, and flexibility. The R-tree indexing in MySQL is still in its infancy, and not a serious competitor to Postgres, and it has a number of other minor defects compared to Postgres. DB2 is designed for an environment where an experienced team is available to set it up and tune it. For data centres with limited manpower, Postgres is very much easier to install and use; it is a well-supported powerful DBMS with adequate performance, and no really serious faults. 11. Summary of Recommendations Structure of the Virtual Observatory Given the current relative prices of processing power, data storage, and network bandwidth, a computational grid is cost-effective only for problems requiring over 100,000 operations per byte, a level that astronomical data reduction and analysis rarely reaches. The data grid model is, however, very appropriate for the Vobs. There is likely to be a significant increase in the total number of data centres: most of the new ones will be small. Commercial DBMS tend to be very expensive, so that cheap or free DBMS are likely to be given preference. Because of limited bandwidth, large datasets need to be processed in situ if possible, with only the results sent back to the user. Large data centres should be encouraged to provide processing power, software, and temporary data storage for external astronomers to make the best use of their holdings. The IVOA members have made excellent progress on the development of common standards such as VOTable and ADQL, but a lot remains to be done, particularly in developing advanced query languages and defining and supporting metadata. Indexing and Cross-matching Many current data centres use DBMS with just one-dimensional indexing for their source catalogues: this is very inefficient, but acceptable for simple services such as cone-searches. Cross-matching is much more data intensive, and a spatial indexing system is highly desirable to support datasets of more than modest size. The pixel-code algorithm, which can be supported by almost any DBMS, is satisfactory on medium-sized datasets, but scales poorly. Spatial joins based on two-dimensional indexing are simpler, faster, and more flexible. Several modern DBMS support spatial indexing, mostly using R-trees. The power of distributed databases is inherently limited by the available bandwidth over wide-area networks, and the latency of these links. In many cases a distributed cross-match could be performed most efficiently by copying the whole of the smaller dataset across the network to the DBMS holding the larger dataset and peforming the cross-match there. Data Exploring and Mining Many data mining packages are available for commerce, although hardly any are designed for the scientific user, who wants to be able to explore interactively large disc-based datasets. Some further effort on evaluating the most promising packages is likely to be worth-while. The SQL language, being results-based rather than procedural, is a particular obstacle to the use by scientists of database technology. The lack of graphical and statistical facilities in DBMS is a serious shortcoming: external packages will have to be used, but data exported from DBMS lose valuable metadata. Methods of integrating such packages with DBMS still need to be explored. Column-oriented storage has advantages for data-intensive querying, and products such as Sybase-IQ are promising for some specialised applications. Object-oriented databases look attractive in theory for some applications, but have been found wanting in practice. DBMS Packages IBM's DB2 package comes from the mainframe world and needs more expertise for its installation and tuning than many sites will have available. Of the packages examined, PostgreSQL seems most suitable: it is reliable, well-supported, powerful, and easy to install and use. It is a bonus that it is an open source package, and therefore usable without cost or licence restrictions. Appendix A: Evaluation of Postgres, MySQL, and DB2 A.1 Documentation Postgres Postgres has four main on-line manuals: tutorial, administration guide, reference manual, and programmers guide. These can be downloaded in PDF or HTML forms, or searched on-line. There is also an attractive interactive version, somewhat wiki-like, in which one's own comments or questions can be appended to the official contents. I posted a question which resulted in several interesting responses by email. There are also two good textbooks on-line. Many Postgres books are also on sale in bookshops; after browsing a number of them in Foyles, I purchased PostgreSQL Developers Handbook by Geschwinde and Schnig, as it was just about the only one to even mention advanced topics such as R-tree indexing. I found this quite useful. The on-line help is useful but rather basic. Software support comes from a number of newsgroups, which are active and helpful. But because these newsgroups have not been properly registered in the Usenet hierarchy the Janet Usenet service has refused to make them available. Actually one group, comp.dbms.postgres.hackers, is provided, probably by accident, but I had to use an alternative news server to see the others. The reference manual is particularly good in telling you not only the exact syntax and facilities of each SQL command, but the differences, if any, between it and Standard SQL92. Documentation on how to use R-tree indexing was somewhat brief, and I had to do some browsing of help files and experimenting to work out which operators on spatial objects were optimised by the SQL engine. The documentation has been improved since then. Mysql There is one large reference manual which can be downloaded from the website of mysql.com. I also purchased two books out of the many on sale: MySQL Reference Manual by Widenius and Axmark (the principal authors of the package), and Core MySQL by Atkinson. These were both quite useful. The documentation on geometric data types and R-tree indexing only appeared on line just before I started my tests, and was somewhat sketchy, but just enough to get me started. The on-line help facilities of the client are pretty basic. Software support, for those using the free version, comes from groups on the mysql.com website. When I had problems loading spatial data I asked about external file formats; my question was not answered satisfactorily, perhaps because there are as yet very few users (but nobody from the MySQL company replied either). DB2 The problem with DB2 is the sheer volume of documentation, which often defeated my attempt to find a particular item of information that I was sure must be present somewhere. One volume contains the index, but reading an index as a PDF file is very tedious. There are 49 main manuals, supplied as PDF files, several with over 700 pages. I found it hard to search the PDFs on line, and sacrificed a small tree to print out four of them and parts of a few others. Even so these make a large pile on my desk. I found that a user called Graeme Birchall had published on-line a book called DB2 UDB V8.1 SQL Cookbook, which contained a lot of useful information on advanced SQL techniques. Also on-line are some useful IBM "Redbooks": I printed out DB2 UDB Evaluation Guide for Linux and Windows and Up and Running with DB2 for Linux, not much over 300 pages each. Between them they gave me basic installation instructions, though these proved confusing and inadequate. I could find very little in the way of introductory or tutorial material. I kept coming across phrases like "ask your administration team to install this additional product for you". If only I actually had an experienced DB2 administration team on hand. Jeff Lusted, who has some experience of using DB2, said that I should try to get hold of the HTML version of the documentation, as the cross-links make it much easier to search. I could find manuals in HTML format only for versions of DB2 earlier than V8. The various DB2 clients provide some on-line help, but nothing that I actually found useful. Because these documents were so difficult to use, I decided to buy a book published by IBM called DB2 Universal Database V8 Handbook for Windows, Unix, and Linux. This was quite useful in itself, but also for its pointers on where to look in the huge manual collection. We had earlier purchased an O'Reilly handbook called SQL in a Nutshell which is a compilation of SQL dialect variations. It is a pity that it covers the quirks only of Oracle, Microsoft SQL Server, MySQL, and Postgres, ignoring DB2. Perhaps this reflects the relatively low profile of DB2 in the market. It was not clear to me whether, as someone not paying for the product, I qualified for direct support from IBM. There are, however, some Usenet groups covering DB2, including one specifically for the DB2 Spatial Extender. When I asked a question, I got helpful answers from two members of IBM staff, and one person who appeared to be just a helpful user. The very low traffic on this group suggests either that the Spatial Extender has very few users, or that nobody has problems with it. A.2 Installation, Configuration, and Tuning Postgres I found the RPM for Redhat Linux, downloaded it, and installed it without problems. A few minutes work with the manual showed me how to disable all the access restrictions and set the server to use our RAID array for all its files. I read a number of documents on tuning Postgres, and made a few changes when I found it was using only a rather small proportion of our one gigabyte of memory, but never managed to detect any significant speed improvement. Unless I missed something important, it looks to me as if Postgres comes reasonably well tuned. MySQL I found the RPM for Linux, downloaded it, and installed it without problems. But configuring it took a lot longer: the RPM was set up to put all its database files on the /var partition which would not have enough space. The server appeared to have a command-line option to change this, and also an environment variable. I tried both of these in various combinations without effect. Eventually I discovered in the manual that the only way to change the disc usage setting was to download a source-code version of MySQL and compile it myself with an altered configuration file. This seemed daunting, and I searched for help on the newsgroups. As nearly always, the problems I encountered with all three DBMS were common ones, and very frequently asked on the newsgroups. Why the software producers take no notice of these common problems I cannot understand. From answers in the newsgroup I discovered that there was in fact a work-around without re-compiling: create a database, move the entire directory to the location I really wanted (this needed root and lots of file permission changes), and then insert a soft-link from the old location to the new one. This worked. I did not find any mention of tuning in the MySQL documentation, and did not do any. It seems to come ready to use. DB2 Downloading DB2 RPMs requires logging in to the IBM Scholars web-site and entering one's user-name and password several times over. Eventually you find a huge list of DB2 products, and I downloaded the Personal Workstation kit for V8.1. This was a huge RPM, around 400 MB, and it took at least five attempts to get a complete download. Installation was then something of a nightmare. For a start it overwrote some files from an earlier installation which I wanted to keep. It requires JDK v1.3 whereas we already had v1.4.1 installed, and I kept having to change environment variables to get the old version picked up. DB2 also requires three specific user-names to be set up: db2inst1, db2fenc1, and dasusr1. The installation wizard claimed it would create these users, but it did not: I discovered afterwards that on systems running NIS this has to be done by hand. I spend several hours trying to get my own user-name granted sufficient privileges to be able to use DB2, but failed, but in the process messed up some of my own shell's settings. The new users were set to use Korn shell, which was unfriendly. I eventually carried out all my tests of DB2 while logged in as db2inst1, and did cuts/pastes from/to my own account for logging etc. It would be excessively tedious to report all the problems I had, no doubt some due to my own lack of experience, but I am sure that it always takes a great deal longer to install DB2 than either of the other packages. The relatively slim IBM book on DB2 contained three whole chapters on tuning, so it is obviously an important topic. On quickly browsing these, it appeared that transaction processing was the main area needing to be tuned. Since I ran out of time and had no interest in transactions, I made no attempt to tune or optimise my DB2 queries. A.3 General Usability Postgres It was easy to start and stop the server, and I could do this without logging in as root. The client was equally easy to start and stop. A long-running query could be cancelled just by typing ctrl/C - this caused the current query to be rolled back if it was doing an update, or otherwise stop quickly and cleanly. There seemed to be no ill effects from aborting queries. The command-line interface, psql, made it easy to recall and edit commands. Multi-line commands could be entered fairly easily. The error messages were good, telling me what was wrong and which part of the SQL statement had caused it. There was a command \timing to toggle timing information given when each operation concluded. The user-interface allowed command-line recall and editing, and external SQL scripts. Although I found Postgres to be generally satisfactory, there were a few quirks: After creating an index it is necessary to perform an ANALYZE operation, otherwise the index is not used in subsequent queries. In dynamic environments the operation has to be repeated regularly, but for a static table once is enough. Index creation takes a bit longer because of this, the times were included in those reported here. Floating-point constants are taken as double-precision by default with no automatic casting to other floating-point types. This causes problems when using an index on a real column. Thus the syntax SELECT * FROM table WHERE vmag BETWEEN 12.5 AND 12.6 ; would not use an index on the (real) column vmag, it needed to be re-phrased thus: SELECT * FROM table WHERE vmag BETWEEN 12.5::FLOAT4 AND 12.6::FLOAT4 ; In a few cases I found that queries took longer when an index was available than when it was absent, or when two indices were provided than when only one was provided. It is possible to influence the query plan, but I did not have time to explore this fully. It is notable that the most common problem posted to all DBMS newsgroups appears to be a complaint that the DBMS is not using an index when the user expected it to be. The EXPLAIN command in Postgres at least gives some information on how it thinks any given query is best evaluated, and some tools to influence its optimiser. Postgres allows user-defined functions to be specified in a number of languages, including its own procedural version of SQL called PL/PGSQL, and used easily in SQL queries. MySQL It was necessary to log in as a privileged user to start the server, but, oddly, not to stop the server, nor start/stop the client. Aborting a query did not seem to be possible without crashing the client, but it was usually possible to re-start it without serious ill-effects. The SQL implemented by MySQL is less complete and less standard than for the other DBMS, though every release brings improvements. Some sub-selects now seem to be supported. There are various back-ends: the one I used was the default one which does not fully support transactions with roll-back, since that was not necessary for our requirements. Data types were a problem: on Postgres and DB2 REAL is a 4-byte type, but FLOAT an 8-byte type; with MySQL the reverse was true. I found that the only way to get a 4-byte and 8-byte floating type for the same columns in MySQL and Postgres was to use non-standard types called FLOAT4 and FLOAT8. MySQL provides the elapsed time of each query by default. The user-interface allowed the usual command-line editing and recall, and use of external script files. MySQL also provides an EXPLAIN command, although the output is not quite as easy to interpret. There does not seem to be any way of influencing the query optimiser, should the explanation be unsatisfactory. MySQL only supports user-defined functions if written in C, and a privileged account is then needed to link the compiled version with the MySQL executable. DB2 There are three different user-interfaces, all of them with their own limitations: The db2 command provides a simple way of entering SQL, here the lines need no semi-colon at the end, so therefore long lines need a continuation marker. I could not find this documented anywhere, but found by trial and error that "\" worked. The db2 interface provided no execution or elapsed time information. There was no command-line recall or editing, no doubt designed for the user who always manages to get multi-line SQL commands perfect every time: I wonder if such users exist? The db2batch command seemed similar, but had the bonus of providing elapsed time information. This could be augmented by cpu-time if db2batch was started with the right command switch. The cpu-time was listed anyway, but was always zero without this switch: why it was not the default is hard to understand. The other switches for db2 and db2batch were quite different for identical functionality, presumably written by different teams who did not bother to talk to one another. Db2batch required a semi-colon, but no continuation marker. It also omitted to provide command-line recall and editing. I would have used db2batch all the time, but it did not support all SQL commands, only those in some (undocumented) core set. The data loading commands had to be issued from db2, not db2batch. The db2cc command invoked something called the "control centre" - a GUI which allowed other GUIs to be started, including the "command centre". This also allowed SQL commands to be entered. These also required a semi-colon, so needed no continuation marker. This would have been a good interface, had it not been programmed incompetently in out-of-date Java. I found that it did not support cut/paste to/from other windows on my screen. From critical comments on various newsgroups I guess that db2cc is not widely used. Other problems I had with DB2 include the following: There seems no way in a single SQL statement to select from one table and have it generate a new table as the result. This is not required by SQL Standards, but is possible in Postgres (using SELECT INTO table) and in MySQL (using INSERT INTO table SELECT). In DB2 it required two statements, one to create a new table (with all the right column names and data types) and then a second one to do the INSERT INTO. This is because, I guess, the normal way SQL is used is just to produce text; the idea that one might want to make a selection and then work on it further is alien to the SQL way of thinking, though this is just what scientists want to do all the time. The lack of such a facility in DB2 is unfortunate (and meant that all my SQL scripts had to be altered yet again). I could not find any way of stopping a run-away query. Control/C and the like had no effect. If I killed the process it seemed to prevent me using database and when loading it left it in an inconsistent state. I generally had to stop and re-start the server (using a different user-name, naturally). In one case this did not work, and I had to re-boot the machine. The transaction log filled up unexpectedly and stopped progress. I could not find out how to eliminate these logs nor how to disable logging, but eventually discovered how to make more space for these logs, and I increased it by a factor of one thousand. The documentation explains that several of these parameters are set by default to values too small for modern computers. This is a pity. There is no EXPLAIN command in DB2, but there is a separate product called Visual Explain. I did not have time to try this out. DB2 allows user-defined functions in several languages, including a procedural version of SQL. A.4 Data Loading Postgres Loading data was simple, especially since the 2MASS data files were designed for use with Postgres. I saw in the manual that a data load operation is performed within a single transaction, so it is all rolled back if anything goes wrong, but I saw no errors. A typical load command is: COPY mytable FROM '/home/cgp/db/data2/psc_baa.csv' WITH DELIMITER '|' ; Nulls were represented by \N in the 2MASS files, the Postgres default, and I used this in the data files I prepared myself from the raw USNO-B distribution. MySQL Loading non-spatial data was just as easy, since MySQL seems to use the same defaults as Postgres. The load syntax is not something that the designers of SQL have ever bothered to standardize, and MySQL requires a slightly more verbose syntax: LOAD DATA INFILE '/home/cgp/db/data2/psc_baa.csv' INTO TABLE mytable FIELDS TERMINATED BY "|" ; DB2 Here the serious problems began. I searched the two volumes of SQL commands for a long time without finding a data load command, and the Redbooks were no help. I suppose DB2 is almost always used in a transaction-processing environment where data is captured live, and rarely needs to be loaded from external files. I finally discovered a separate PDF manual called Data Movement Utilities Guide and Reference a mere 429 pages long. It eventually yielded up the secrets of the copy command. I then found that it could not be used from the db2batch environment, or the db2 gui, only from the db2 command-line interpreter. The typical syntax is: LOAD FROM '/home/cgp/db/data2/psc_baa.csv' OF DEL MODIFIED BY COLDEL| INSERT INTO mytable ; But data loads failed repeatedly. At first I thought that it was the date/time fields which were causing problems: with 60 fields per line and hopeless error messages, it took me some time to eliminate each possibility. Tests with samples of a few hundred or thousand rows sometimes worked fine. Eventually it seemed that the nulls were not accepted. The manual suggested (without being definitive on the subject) that there was no external representation of nulls, except for the absence of data between two field delimiters. Unfortunately every such null-by-default gave rise to a warning message. I left one data load running when I went home at night; the messages were still scrolling off my terminal screen at the rate of hundreds per second when I arrived the following morning. I had to abort this run, which left the database in a mess, and eventually I had to reboot the machine. Since all the nulls were in numerical columns (magnitudes) I found a work-around by using the Unix tr utility to convert each null into the value of "-1" which was out of the normal range. By this means I finally managed to load some strips of the 2MASS data. I did not get around to converting these values back into nulls, though I suppose that an UPDATE statement would have been able to do that. Even so each load operation generated lots of incomprehensible messages, of which this is a typical example: SQL3501W The table space(s) in which the table resides will not be placed in backup pending state since forward recovery is disabled for the database. Although I could not get timing information as with other DB2 commands since the db2batch facility would not load data, the LOAD command reported the clock times at the start and end, so the performance could be measured. The only good point of DB2's data loading was that it was fast, and I noticed that it used the cpu time of both processors. The times taken to load 5.1 million rows of 2MASS were as follows: PostgresMySQLDB2116 secs205 secs44 secsGiven that nulls are an essential element of nearly all astronomical tables, and that finding a suitable out-of-band value to represent them is a non-trivial undertaking, I think that if it is true that DB2 has no satisfactory way of representing nulls, this omission forms a very serious obstacle to its continued use. But the loading performance if DB2 is very impressive. A.5 Spatial Indexing Postgres Loading spatial data from a text file required a slightly odd format with extra parentheses, but I had no trouble in loading the required spatial column, nor in writing a program to convert USNO-B data to the required form. The basic spatial object is a rectangle, specified by the coordinate pair (x,y) of two opposite corners, and one can create an R-tree index on these bounding boxes. The SELECT statement can use operators (such as &&) to test for overlap of the rectangles. It was easy enough to read the rectangle coordinates from an external text file, or to generate the rectangles on-line using an UPDATE statement (which is obviously simpler). There is little to report here: spatial indexing worked as expected, and was reasonably fast. The simple R-tree provided by Postgres indexes a rectangle, the dimensions of which have to be rather stretched when encompassing an error region at high declination. A better way of doing this is promised by two developments from the Sternberg Astronomical Institute in Moscow, pgSphere, which will provide a 2-d index on a surface covered by spherical-polar coordinates. A related project, pgSphere, adds certain astronomical functionality to this. Nothing comparable to this is available for any other DBMS, as far as I am aware. MySQL MySQL has only added spatial data support in its latest (alpha) release, and it shows many omissions which will no doubt be rectified over in future releases. The software is aimed at the GIS market, and uses R-trees for indexing. The documentation was very sketchy, and some trial and error was needed to discover what actually worked. The first problem was to load the data, as no external format for the spatial data type was documented. I asked in a support newsgroup, but got no answer. I think this may be a feature still missing. The only alternative was to use INSERT statements to load the spatial data, but loading one row per INSERT would have taken far too long. I found by experiment that I could not load a large table in a single INSERT statement, but that 1000 rows/INSERT appeared to work. I therefore write a new utility to convert the USNO and 2MASS data files into the appropriate SQL INSERT statements. These were very verbose. Finding an intersection or overlap was also much more verbose, as there were no operators handy, only functions. This verbosity might have been acceptable had the performance been reasonable, but as noted below, the MySQL spatial index was many times slower than that of Postgres. DB2 DB2 spatial indexing comes in an additional package, called the Spatial Extender. I downloaded it with difficulty (another 300 MB of software and flaky FTP connection) but it eventually installed correctly. But it would not work. I eventually discovered, via the control centre, that it was not licenced. I asked the IBM Scholars Programme administration how I got a licence and got an answer which was very helpful (but only after a week). It turns out that the licence can be downloaded from their web-site (indeed I had already done this) but it needs to be copied to a new location and then a licence installation procedure is necessary. Unfortunately by the time I got all the necessary details, I had insufficient time to complete testing this feature. The manual is fairly comprehensive, but at 574 pages, as intimidating as the others. One immediate difference is that IBM's Spatial Extender does not use R-tree indexing, but a multi-level grid file. These are not self-adjusting like B-trees and R-trees, but require the user to consider the range and granularity of up to three levels of the grid-file. Although the data are expected to be floating-point values (geographical longitude and latitude are expected), they are scaled and then converted to 32-bit integers. These scaling factors also have to be chosen by the user. Another problem then presented itself, just as for MySQL, the lack of an external format for spatial data. I posted a question about this to the dedicated newsgroup ibm.software.db2.udb.spatial, and got useful replies, including a suggestion for populating the spatial object from the (ra,dec,radius) triplet. One has to convert all the numerical values into character strings because the polygon function will only take string arguments, which is very awkward. It would be nice if the R-tree implementation in Informix were to be retro-fitted to DB2. A.6 Performance: Joins using R-trees This section used only MySQL and Postgres, as I did not have time to get DB2's spatial extender working. The main test joined a section of 2MASS with an overlapping section of USBN-B. 2mass: 5 million rows of data, file psc_baa covered 0 to 360 degs RA, and 0.0 to 1.67 degs Dec, but with just these columns selected: RA, DEC, position-error, three magnitudes, error-box. USNO-B: 3.6 million rows of data, covering 0 to 360 degs RA, 0.0 to 0.6 degs Dec., with these columns selected: RA, DEC, position-error, five magnitudes, error-box. The tests were carried out on the main node of hydra, which has dual-Xeon 2.2 GHz processors, and 1 GB of memory, the times are in seconds.  HYPERLINK "http://wiki.astrogrid.org/bin/view/Astrogrid/?topic=CrossMatchingReport&sortcol=0&table=1&up=0" \l "sorted_table" \o "Sort by this column" Elapsed times in seconds  HYPERLINK "http://wiki.astrogrid.org/bin/view/Astrogrid/?topic=CrossMatchingReport&sortcol=1&table=1&up=0" \l "sorted_table" \o "Sort by this column" Mysql  HYPERLINK "http://wiki.astrogrid.org/bin/view/Astrogrid/?topic=CrossMatchingReport&sortcol=2&table=1&up=0" \l "sorted_table" \o "Sort by this column" Postgres Load 2mass, 5 million rows 205 116 Load USNOB, 2.6 million rows 153 93 Create spatial index on 2mass 488 617 ANALYZE (needed for Postgres)  67 Create index on USNOB 347 442 ANALYZE  27 Join tables on 1" circle 4030 283 total 5223 1645 The speed advantage of Mysql at all the earlier stages was lost in carrying out the join. The support for spatial data and R-trees has only just been introduced, so it is perhaps not surprising that it has not yet been optimised. On these figures, Postgres is the clear winner. A.7 Simple Query Performance It also seemed worth comparing the performance of Mysql and Postgres with a more substantial chunk of data. These tests used ten files of 2mass data, totalling around 50 million rows, and the times are in seconds. OperationMysqlPostgresDB2Load data 1660 4030 2154Sequential scan for H_M between 12.010 and 12.011 192 264 1327Create B-tree on column H_M (+ANALYZE for Postgres) 2207 1265 1709Indexed access for H_M between 12.010 and 12.011 0.15 419 0.05This Postgres result was so odd that it was repeated: subsequent indexed selects took 3.9 seconds, and 0.7 seconds. Presumably some information needed to be stored in the cache before the query was executed efficiently. It was not clear why DB2's sequential scan was so slow - the cpu seemed to be very lightly loaded while the query was running. Given the amount of documentation devoted to tuning, it is likely that tuning by an expert would produce a substantial speed increase. Inner and Outer Join The outer join (which copies unmatched rows from one table into the results) is important in astronomy, since unmatched sources are often of scientific interest. This test was only carried out using Postgres and R-trees: the inner and outer joins took about the same times, within limits of measurement. A.8 Summary IBM's DB2 has the reputation as a reliable product with good performance and it competes head-on with Oracle in the commercial market, but its sheer size seems to make it unsuitable for installation by the inexperienced and unaided astronomer. There are also a number of deficiencies in the friendliness of its user interfaces. Although the spatial indexing was not tested, the use of a multi-level grid file of scaled integers seems much less attractive than the R-tree, which is self adjusting to one's data range. At present MySQL is used by many more astronomical sites than Postgres, but the latter appears to be gaining ground, particularly for the handling of large datasets such as 2MASS. The figures presented above suggest that MySQL is faster than Postgres only in a few operations, and the speed advantage is with Postgres for complex operations or ones on very large tables. Postgres has somewhat better documentation and support for established standards. The spatial data handling of MySQL is not yet ready for serious use, but this feature was only introduced very recently. The R-tree indexing of Postgres is reliable and performed well. In summary: Postgres seems to have few shortcomings, and can be warmly recommended. References [1] http://wiki.astrogrid.org/bin/view/Astrogrid/ScienceProblems [2] http://www.wintercorp.com [3] http://research.microsoft.com/research/pubs/view.aspx?tr_id=655 [4] http://wiki.astrogrid.org/bin/view/Astrogrid/SkyIndexing [5] http://research.microsoft.com/~gray/papers/SDSSArchive_OO_to_SQL.pdf [6]  HYPERLINK "http://adass.org/adass/proceedings/adass02/O7-3/" http://adass.org/adass/proceedings/adass02/O7-3/ Appendix B2 Grid Middleware for the Virtual Observatory Report by Guy Rixon on behalf of the Grid Technology work-group 2004-01-28 Abstract The grid paradigm is summarised: the Virtual Observatory is shown to be a grid, whether or not it uses software products specifically built for grids. Available middleware is reviewed for the following areas: computational services; contextual web services; data grids; access control. In all cases, the grid middleware is found to be a partial solution at best to the VObs problems. In many cases, the partial grid solution overlaps with and is incompatible with emerging standards from the IT industry. Five scenarios are presented for incorporating grid software into the VObs, ranging from total dependence on OGSA to total exclusion of grid products. The best use of the grid middleware seems to be at the edges of the VObs tree of services. Here, it can possibly allow access to special resources for exceptional use cases. Most grid middleware is not well suited for the mission-critical parts of the VObs. However, some aspects of grid software could be made pervasive in the VObs. GridFTP and the grid security infrastructure are the strongest candidates. What makes a Grid There exists special middleware written for making grids. It is different from the middleware that Virtual Observatory (VObs) projects have used to date. Is this middleware useful to the VObs? What does it achieve? A grid is a collection of on-line services with a few special features not found in the world-wide web or in typical web-service installations. There is a market of commodities: services with equivalent semantics that can be used interchangeably. Use of these services may be free, or it may be controlled by barter or the exchange of money. The services are listed in registries. The services carry out long-running operations: loosely, batch jobs. These jobs can run for longer than the typical up-time of a machine in the grid, so cannot be controlled via a chain of web services that remain connected for the duration of the job. Instead, the grid infrastructure allows the clients and agents in the chain of command to start the job; to detach from the services doing the actual work; and to reattach later to steer the job or to retrieve its results. This asynchronous, detachable mode of operation dictates the architecture of the grid. It shapes the operations of the services in the grid and dictates that the grid itself stores the results of its job steps, rather than sending them to the desktop for storage. Services doing practical work in a job are supervised and coordinated into workflows by other services further up the chain. Results from one service are fed as inputs to others in the workflow. To support this, a peer-to-peer system for exchanging data is provided as a separate feature of the architecture. Since data in the grid are sometimes private, and the resources in the grid are valuable and scarce, access to data and services is controlled. To preserve the detached mode of usage in a secured grid, there is a single sign-on system in which the users can delegate privileges to software agents. The extent of the single-sign-on system defines a Virtual Organization (VOrg) that typically includes more than one conventional organization. The virtual observatory (VObs)1 aspires to all these features. It is clearly a grid, even if it is not built from branded grid technology. Already, within VObs projects around the world, these features are being provided. The principal question is whether the VObs grid can be built better by using products specifically designed for grids. Different grids for different commodities Various commodities are shared on grids: algorithms, CPU cycles, data-storage space and mirrored copies of particular data-objects. A grid of services, called in client-server fashion, supports the sharing of algorithms. This kind of grid has three benefits: clients can run the algorithms without the cost of installing the software locally; the algorithms can be run at the site of the data they process, which conserves network bandwidth; and the algorithms may run on faster computers than the users client computer. This network of services becomes a grid when algorithms become commodities, such that users and their agents can choose the best site for the job from a registry of services that do the same work and have the same interface. The services in the grid may be job manager services. These submit batch jobs to processor queues. In this case, the shared algorithm is the command shell of the underlying operating-system. By sharing this, the services make CPU cycles a commodity, since the user, not the service, defines the computation. A network of job-manager services becomes a grid when the services have common interfaces and are catalogued in a registry. Data-storage is shared by allowing either user agents or services to read or write files to any grid location where they have access rights. If only the user agents have this access, then data can only flow between services via the users desktop, which may limit the speed of execution of a workflow. When the services have the same access, peer-to-peer sharing of data is the norm, and this allows the system to exploit fast network paths between service sites. As a bonus, coupling between entities in the grid is reduced. A data-sharing network becomes a data grid when the storage sites are catalogued in a registry, when all the parties in the grid can access the storage through common interface and when the system has a common way of expressing access rights for users. Currently, most data-grids just store files. Later grids may give the same access to database tables. Data-mirroring systems maintain copies of files to increase availability and reduce the need to fetch remote files over limited network-bandwidth. Mirroring is a well-established technique, but, in typical installations, only a few applications know the location of the mirrored copies and the meaning of the file. If the system can express and record the meaning of the files and the relationships between the copies, such that all applications can use this information, then the files themselves become commodities and the system becomes a grid. A grid is only worthwhile if the commodities it shares have greater value than the cost of building and operating the grid. The first grids were networks of job-managers services sharing CPU cycles, since CPU power was seen as the most valuable commodity and the easiest to share. Grids sharing specific algorithms in custom services received less attention, since algorithms were seen as less valuable than CPU cycles. Proper data-storage and data-mirroring grids are extremely rare; access to data is recognized as a valuable commodity, but the data grids are harder to build. Practical grids combine the techniques and share more than one commodity. Most grids sharing CPU cycles also share files, although few provide a full data grid. Data grid implementations generally provide both mirroring and storage. Therefore, most grid toolkits address parts of all the problems. Computing for observational astronomy is limited more by data volume, data complexity and the difficulty of setting up software applications than by lack of CPU cycles. Most use cases can be realized by installing affordable, extra computers at the sites where the relevant data are stored. Therefore, the traditional CPU-sharing grids have limited value, and grids of services in the VObs are more likely to contain algorithmic services than generic job-manager services. Conversely, numerical modelling in theoretical astronomy is entirely limited by CPU power and benefits directly from CPU-sharing grids; but the VObs is not funded to support theory work. Intragrids, extragrids Given an existing network of services, there are two ways to add grid products. In an intragrid, components and services forming a complete grid are hidden behind a faade that conforms to the VOrgs existing conventions. Typically, a grid is attached to one web service in the VOrg as a private resource. Users in the VOrg get the power of the grid by addressing the faade service. Applications and middleware in the general VOrg are not aware of the presence of the intragrid. In an extragrid, the grid components, with their conventions, standards and protocols, are visible to applications; the grid services are listed in the VOrgs registries. Applications and middleware in the VOrg have to adapt to the grid software in order to use the resources it controls. The VOrg becomes dependant on the grid technology. A network that is an intragrid for one VOrg may be an extragrid for others. An example of this is the TeraGrid which is clearly an extragrid to its member institutions: the processing power is distributed between several legal organizations. The AtlasMaker service for the VObs uses the TeraGrid as an intragrid for its own purposes of combining images, but does not allow other VObs entities to start arbitrary computations on the TeraGrid. Intragrids are clearly easier to introduce to the VObs than extragrids but they dilute the value of grids. To get the most benefit from the grid paradigm, the VObs should standardize on one set of grid middleware and that set should become an IVOA standard for the extragrid. In addition to this, and in the interim before IVOA makes its choices, intragrids can be used to try out the available products. These intragrids need not use common technology, and there is no need to make the middleware for the intragrids interoperable; each intragrid only needs to interoperate with the faade service that links it to the VObs. Ultimately, technology for intragrids is chosen by service providers and technology for the extragrid in the VObs is chosen by IVOA. AVO need not and should not dictate choices to the service providers and can influence, but not dictate or ignore, the decisions of IVOA. Once IVOA has chosen the standards for its extragrid, AVO may only choose amongst compatible implantations of those services. Standards bodies The Global Grid Forum (GGF [1]) defines the grid-specific standards. It is a community-based operation, proceeding by open debate. GGF is currently standardizing a number of grid technologies for which prototypes exist in the field. Indeed, GGF normally standardizes existing practice. The Open Grid Services Infrastructure is an example. Some higher-level web-service standards are controlled by the Organization for Advancement of Structured Information Standards (OASIS [2]), a consortium of IT-industry companies. OASIS standards are usually made available to the community before there are trial implementations. The WS-Security standards are examples. Standards for XML and for the lower-level parts of web-services are controlled mainly by the World-Wide Web Consortium (W3C [3]). Examples are SOAP and WSDL. Some of the lowest levels of grid middleware conform to standards set by the Internet Engineering Task Force (IETF [4]), e.g. the X.509 standard for identity certificates. Software for computational grids Web services In the beginning, grid middleware was defined in the traditional way for Unix services: servers running as daemon processes, with one daemon per service; network communications via TCPP/IP sockets; custom communications protocols layered on TCP/IP; one TCP port-number per protocol; hence one port per service. These methods limit development by forcing application programmers to work at too low a level and by restricting the reuse of communications code. Very little of the middleware can be shared between different communications protocols. These techniques are now being superseded by web services, defined as on-line services communicating by exchanging XML documents over established network-protocols such as HTTP. The use of XML allows much richer communication, which supports services with complex semantics. The use of standard protocols at a higher level than TCP/IP greatly eases the development of clients and services. Web services use XML be definition, but can have many different ways of using XML. Effective middleware requires standards for the logistical packaging of messages and for the description of the messages that a given service accepts. The IT-industry standards for this are the Simple Object Access Protocol (SOAP [5]) and the Web Services Description Language (WSDL [6]). WSDL can define the syntax of the messages of any web service at the level of XML elements with given types. It can also describe the pattern of messages e.g. request/response, unacknowledged transmission from client to service, asynchronous notification from service to client for a given operation. WSDL allows communication with the service to be defined in terms of XML schema. WSDL is precise enough that communications code for talking to a service can be derived from that services WSDL. The definition of commodity classes for services i.e. groups of services that can be used interchangeably is made easier by WSDL. WSDL is the glue that binds services together. It allows clients and services written in different languages and with different programming-toolkits to interoperate reliably. Services that lack WSDL only interoperate by chance. WSDL defines the basic schema of messages used by a given service. SOAP defines a wrapper or envelope for that schema that is common to all web services: the service-specific payload within the envelope is called the body of the message. In addition to the body, SOAP messages may carry various forms of header, and these are used to express logistical aspects of the transmission of the message: e.g. security credentials of the caller, routing, encryption for privacy, and the contextual relationship with other messages in the same operation. Bodies of SOAP messages can be literal XML documents, controlled by schemata provided by the author of the service, or they can be calls to object methods in the service, encoded according to a schema that is part of the SOAP standard; the latter is called Remote Procedure Call (RPC) encoding. RPC-style messages were the original aim of SOAP (and the origin of its name), but are now considered an impediment to interoperation. Document/literal messages are favoured for modern services. The canonical web service has therefore become one which: communicates using XML; uses a standard, medium-level protocol to move the bytes, normally HTTP; describes its messages and patterns of messages using WSDL. The VObs should be building services of this kind for its extragrid. To do otherwise would make the services and clients harder to write and the interoperation harder to arrange. IVOA has already agreed to base its grid on web services. We should note, however, that the web-service paradigm applies mainly to control messages in a client-server situation. I.e., web services are ideal for invoking resources in the computational grid and for moving metadata. They are less well suited to moving bulk data. For the movement of bulk data in the data grid, we should look to other kinds of protocol. Web services need not be SOAP services; there are other ways to package messages and the two simplest are already in common use in astronomy. HTTP-get: invoke a service via its URL and embed the parameters of the invocation in that URL; receive the results of the invocation as an XML document; the return document is entirely specified by the service with no wrapper layer that is common between services. HTTP-post: invoke a service by sending an unwrapped XML document; receive another unwrapped XML-document in return. Both can be described in WSDL; both are simpler to implement than SOAP services. Why then use SOAP? SOAP is unnecessary for services with simple semantics that are used in isolation. When services are combined in context, then SOAP headers become useful. These contexts are defined by the middleware layers that combine the services; authors of services may not be aware of the contexts when the services are written. Therefore, VObs services should use SOAP in order that the contextual headers can be added later without disrupting the interfaces of the services. The next section discusses the addition of context to services Contextual web services and OGSI Simple web services are synchronous, stateless and return results over their control channel. I.e., each invocation of a service blocks until the operation is complete, returns the results of the operation to the caller and then forgets the context of the operation. Subsequent invocations take place in a separate context. If the client breaks connection before the operation is complete, then the results of the operation are lost. Synchronous services are good for quick operations because they are easy to implement. The grid, however, calls for long-running operations where the caller is not continuously connected. Grid services commonly need to be asynchronous. This means that grid services need to remember the state or context of an invocation such that the caller can later retrieve the results. They also need a way to notify the caller asynchronously of progress. The Open Grid Services Infrastructure (OGSI [7]) is GGFs standard method for allowing web services to remember the state of a transaction and hence to run asynchronously. Web service context (WS-CTX; a part of the WS-CAF framework [8]) is the IT industrys draft standard for the same function; it is an OASIS standard. The two standards are fundamentally incompatible. OGSI-compliant services are SOAP services that distinguish contexts by assigning a new URL to each context; they require that the application software set up this URL explicitly using a factory service. OGSI complicates the semantics of all grid services but leave the syntax of the invocations simple. WS-CTX-compliant services are SOAP services that distinguish contexts by notations in the headers of their messages. They complicate the syntax of messages in order to keep the semantics of the service simple. OGSI defines a general notification-interface for the client over which any message can pass. It does not define a standard protocol by which a service can signal the completion of an asynchronous operation. WS-CTX defines a specialized notification-interface for the client with a specific way of signalling job complete. It does not support notification of arbitrary events. Some higher-level protocols may be needed for some use cases. Notably, there may be a need for web-service operations to be made transactional, such that either all operations in a workflow succeed or all services are rolled back to the state they had before the start of the workflow. The WS-Transaction (draft) standard of OASIS (another part of WS-CAF [8]) defines protocols for this; it is built upon WS-CTX. OGSI has no equivalent protocol. Parastatadis et al. [9] have compared OGSI with the OASIS standards. They conclude that OGSI is only a partial solution to contextual services; that complicating the semantics of the services (OGSI) causes more problems that complicating the syntax of messages (WS-CTX); and that using OGSI deprives grid services of support from most industry standards and the tools that follow those standards. It is unlikely that the IT industry will abandon WS-CTX and switch to OGSI. Some industrial players may support both standards, but they are likely to put more effort into supporting WS-CTX. OGSI, in its current form, may or may not survive. If it does survive, then it is likely to be restricted to the scientific community. If the VObs wants to write contextualized web services, then these services should not use OGSI but should follow the industry standards. If the VObs wants to use grid services written in the grid community, then it will have to write OGSI clients-software. WS-Reference Framework As this report was being finalized, new standards called WS-Reference Framework (WS-RF 10]) were announced jointly by the Globus Alliance, IBM and HP. WS-RF attempts to rewrite OGSI so that it is compatible with the OASIS standards and with standard tooling for web services. WS-RF may eventual emerge from GGF as OGSI 2. WS-RF differs from OGSI in that it uses SOAP headers to identify contexts instead of dynamic addresses for service instances. In this, it uses similar techniques to the WS-Context standard, but bases its syntax on WS-Addressing instead. The other features of OGSI, such as control over the lifetime of resources, notification of events, grouping of services, etc., are included in WS-RF. A first reading of WS-RF suggests that it is more nearly compatible with existing web-service standards than OGSI 1.0. However, it still does not interoperate with standards such as WS-Transaction that need WS-Context headers. There is currently a debate as to whether key parts of WS-RF are a redundant duplication of WS-Context. There is a suggestion by the Globus alliance that OGSI 1.0 will be discarded in favour of WS-RF, starting with the release of Globus Toolkit 4 in autumn 2004. Therefore, OGSI is clearly now unsafe for VObs use. WS-RF may be safe for the VObs to use; it is too early to tell. OGSI and OGSA The Open Grid Services Infrastructure (OGSI [7]) was introduced in the previous section. It is a standard for expressing state or context in web services. The Open Grid Services Architecture (OGSA [11]) is a factoring of generally-useful functions into standard, commodity services. OGSA is based on OGSI; OGSA components can only function properly in a grid with OGSI semantics. OGSA may later be redefined in terms of WS-RF semantics. OGSA has a wide scope. The areas to be covered include: defining and managing VOrgs; collections of related services; managing deployed services; secure communications; asynchronous messaging; security; managing distributed data; remote execution of (user-defined) programmes; workflow and orchestration of services. For each of these areas, the draft specification proposes specific web services, but describes them only in prose; the current draft does not include the schemata needed to implement these services in an interoperable way. Essentially, OGSA is intended to standardize all parts of a grid that are not specific to that grids applications. It is meant as a complete environment for managing distributed applications without defining those applications. The concept of a computing platform is prominent in the specification. OGSA has a very strong emphasis on the computational grid. In the introductory section of the specification, program execution services are detailed in six pages of text while data services are granted only half a page. In the lists of services, only three sections out of 26 are to do with the data grid. It seems likely that initial, practical versions of OGSA will not support a full data-grid. There is also a bias in the specification towards computations as jobs i.e. as non-grid programmes running under control of grid-aware batch schedulers instead of as services providing special algorithms. The OGSA platform proposed for a computing node in the grid is very general and relatively complex. It is entirely appropriate for OGSA to be concerned with general job-management services and not with algorithmic services for specific disciplines of science. However, there is a danger that OGSAs orchestration and workflow services will come to require the full OGSA compute-node platform in order to drive any service. It may become expensive in effort to deploy a single, algorithmic service on one site. OGSA is currently vaporous. The specified services cannot be implemented from the existing descriptions. Some of the services are clearly intended as standard versions of existing art (e.g. batch-job-manager services in the Globus Toolkit); others are new functions for which no common prototypes exist. OGSA does not yet exist, either as a de jure standard or a de facto standard. Given GGFs excellent but lengthy process of document review, it is unlikely that a useful OGSA standard can exist before 2005. OGSI implementations OGSI is defined by its WSDL and XSD schemata; services can be coded directly to this standard without requiring special tools or libraries. However, OGSI is sufficiently complex that most authors of grid services work with a reusable toolkit that implements OGSI with a relatively simple set of APIs. There are currently at least five OGSI implementations. Globus Toolkit 3 (GT3), for Java. [12] Fujitsu Unicore, for Java. [13] University of Virginia, for .NET. [14] MS.NETGrid from EPCC, for .NET. [15] OGSI::Lite, for Perl. [16] AVO and AstroGrid have investigated GT3 in depth. Several trial computational grids and data grids have been built. GT3 has sufficient function to support use of OGSI but currently lacks quality; building grids with GT3 is unreasonably error-prone and expensive in effort [17]. University of Virginias product was demonstrated at GGF9. It seems to reduce the work involved in the writing services. Broadly, web services can be written more cheaply with C# and .NET than with Java and J2EE [18]; the Virginian implementation of OGSI seems to have a similar advantage over GT3. However, no detailed tests have been made. The extension of Unicore to OGSI services is a beta-test product at present (the Unicore system itself is much more mature). It depends on the Glue toolkit for web services [19], which is a commercial product. AstroGrid has investigated the Glue toolkit [20] for web services but not for OGSI services. Glue seems to simplify and accelerate the production of web services compared to Apache-Axis, so there is some hope that Unicore may be a more efficient platform for coders of grid services than GT3 (GT3 is based on Apache Axis). The other toolkits have not been investigated. Condor Condor [21] is a product for building a computational grid inside one organization. Essentially, it is a way of building an intragrid when that grid supports only job-manager services. Condor has been in service and under active maintenance for 15 years. It is very highly regarded. Condor can be used with the Globus Toolkit to share computers between organizations. Software for data grids GridFTP The conventional FTP protocol [22] is sufficient for moving files between services when: the data are in the public domain and may appear on a public file-server with no access control; the transfer is driven by the receiving server (a pull transfer). I.e., if anonymous downloads are good enough for a use case, then conventional FTP is good enough. For uploads (push transfers), and for restricted downloads of non-public files, conventional FTP uses passwords. This is unacceptable in a grid: software agents start the transfers and a user may not be available to give the password. The GridFTP protocol [23], which is a GGF standard, extends conventional FTP with GSI security such that the security tokens used in the computational grid can also be used in the data grid in place of passwords. This enables the computational grid to drive the data grid. Grid FTP also has features transfer striped over multiple connections and control of buffer sizes that improve performance with respect to conventional FTP. Transfers in the data grid must be robust against network failure. It is inefficient to restart a transfer of 10TB from scratch because of a network failure halfway through. A grid needs a reliable file-transfer service and that service needs to be able to restart transfers. GridFTP provides the ability to restart transfers from markers in the data stream. A GridFTP server is provided in the Globus Toolkit. Client software for C is provided in the Globus Toolkit itself and for Java in the Globus Commodity Grid Kit for that language. Reliable File Transfer Service The Globus Toolkit version 3 includes a web service that controls transfers between GridFTP servers [24]. The service remembers transfer state (even across restarts of the service itself; it uses a RDBMS for persistence) and restarts failed transfers. The Globus RFTS uses GridFTP to move the files. No tests have been made on this implementation, but the basic idea is necessary for running the data grid. Replica managers A data grid may support replication or mirroring of files in order to keep data closer to the site of processing. Some users of grids (e.g. GridPP [25]) regard this as the primary role of the data grid. Therefore, several replica-manager services are available. A replica location service [26] is available with GT3. This is based in part on work of the European Data Grid. GGF is proposing other RLS for standardization. OGSA-DAI and LDAS OGSA-DAI [27] is an interface from the grid to relational and XML databases. It is a set of OGSI-compliant web-services of which the Grid Data Service (GDS) is the primary part. A GDS instance represents a database connection and the associated state: e.g. it retains enough state to support a cursor on the results of a query. When OGSA-DAI is used with relational databases, which would be its main use in the VObs, it acts as a JDBC redirector with added security. A request from a grid user is authenticated using Globus message-level security (see below). OGSA-DAI maps the grid identity of the user to a local user of the database and forwards the query over JDBC to the separate DBMS. OGSA-DAI does not itself provide or require a specific make of RDBMS. OGSA-DAI does not, by default, do any transformation of the query or the results. Therefore, it does not abstract away the implementation details of the DB. This makes it unsuited as the primary interface to relational archives in the VObs. Data publishers in the VObs could force OGSA-DAI to do the transformations necessary for a VObs-standard interface [28], but it would be much easier to use a web service with a conventional JDBC connection to an archive database. However, two features of OGSA-DAI make it useful in the VObs data-grid for special cases: access control for writeable databases and GDS-to-GDS transfers. OGSA-DAI supports normal Globus-style access control. This makes it relatively easy to grant grid users write access to selected databases. It should be possible for users to upload tabular data in a VOTable into a GDS and use on those data the full querying-power of the RDBMS. Clearly, this feature could be coded specially for the VObs, but OGSA-DAI has it in reusable form. The results of a query in one GDS may be written directly to another GDS without first being exported to a file and explicitly moved between sites. This supports the operation of a distributed data warehouse, which may become essential for large-scale data-mining in the VObs. The results of initial queries on many, scattered archives can be collated in a data-mining centre where queries with table joins and whole-table scans can run more efficiently. The final results can be exported to yet another database for long-term storage. Again, these facilities could be coded specifically for the VObs, but OGSA-DAI already has them. For the data-warehouse scenario, OGSA-DAI can be used with a separate, web-service faade that handles the astronomical details of the work, leaving OGSA-DAI to handle the application-independent parts. I.e., OGSA-DAI is being used as part of an intragrid. In this mode, the heavy data-mining can be delegated to borrowed resources outside the normal VObs, e.g. on a national science grid. OGSA-DAI was the original implementation. ELDAS [29] is a re-implementation of the same specification by edikt and may have better performance than the original; ELDAS is supposed to be fully interoperable. The DAIS working group of GGF [30] is working on an expanded specification based on the OGSA-DAI concepts. Storage resource broker Storage Resource Broker (SRB) [31] combines reliable file-transfer and file-mirroring to make a self-contained data-grid. It also allows files held remotely on the grid to be opened directly by programmes, rather than explicitly copied and opened locally. In SRB, a network of agents brokers manage all storage in the data-grid using custom protocols. Programmes use files via a custom interface similar to the C standard-IO library, and all files appear local to programmes. Files are copied and cached by the broker network as needed to maintain the illusion of local files. The location of files is stored in a central database and the broker network refers to this database. SRB has powerful administration tools for making mirror copies and for migrating files between storage locations. It is particularly good at moving files to and from tertiary storage; SRB is a great aid to running robot tape-archives. SRB is very powerful, but it significant drawbacks. It is a closed system. Source-code is provided, but no third-party products can work on the stored files. The details of how files are stored are a private part of SRB. The file-metadata database is central and cannot be mirrored. If that database is unavailable then the entire data-grid fails. The ability to open and access remote files only works for programmes compiled with SRBs special APIs. Other software would have to be rewritten to use this feature. The central catalogue of files is naturally owned and controlled by one site in a grid. It is possible to federate SRB installations for adjacent grids, but a site wanting to join an existing SRB grid must give up control of its grid-attached storage. SRB deals only in flat files. It does not work with relational data in the way described for OGSA-DAI. These drawbacks suggest that SRB is not well suited to extragrids and is not appropriate for the extragrid in the VObs. However, it is ideal for individual VObs sites with distributed storage and may be useful for building intragrids at VObs sites. Access control Most grid operations involve changing the state of one or more services and this makes the services more vulnerable to misuse than would be the case with stateless services. A grid needs to allow access to vulnerable services only for authorized users. With conventional web services, this access control is exceptional; for a grid is the norm. Authorization checks are pointless unless the users identity is known. Access-control systems need to provide authentication of identity on all accesses to services. This in turn requires a system for registering identities that spans the entire grid. The limits of a grid and a VOrg are defined by the range over which its users identities are recognized and trusted. Traditionally, authentication is done with passwords specific to one site and authorization is done piecemeal within each site, using file permissions. This does not scale to a grid; it is generally considered too hard to set up the local authorizations and too limit to prompt the user (who may not be continually present during a workflow) for passwords at each access. Grid middleware is converging on a solution based on these principles: digital signature (based on public-key cryptography) for proving identities; public-key infrastructures (PKIs) for assigning grid-wide user names; authorization servers for sharing knowledge of users privilege around the grid. These techniques combine to provide single-sign-on operation of the grid where a user only supplies a password once on starting each session. Public key infrastructure for grids Grid middleware generally implements authentication using the Grid Security Infrastructure (GSI [32]); this is derived from prototypes in early versions of the Globus Toolkit. GSI requires the authenticating party to have an X.509 [33] certificate containing an X.500 Distinguished Name (DN), and the DN is that partys grid-wide user-name. A Certificate Authority (CA) a third party trusted by all users and service providers in the grid signs the certificate digitally, thus preventing forgeries. Before signing, the CA makes some checks, typically using real-world identity documents such as passports, of the applicants identity, such that certificates are not issued falsely. The procedures by which certificates are signed and issued, plus the format in which the format in which the certificates are written, forms the Public Key Infrastructure (PKI) for that grid. The quality of the off-line identity checks in a PKI defines the security of the grid using the PKI. If the security is very lax, then some potential service-providers may be unwilling to donate resources to the grid or to any network that interoperates with the grid. In particular, job-submission services are dangerous to use with a lax PKI as they give command-line access on grid nodes to anybody who can fool the CA. Algorithmic services are less vulnerable in this respect. The minimum requirement for a party to use a secured grid service is that the party can present a GSI-compatible certificate with the request. There are many possible uses of the X.509 format (the X.509 specification is regarded in the IT industry as unreasonably vague). It is currently unclear whether certificates issued by commercial CAs, such as Verisign, are compatible with GSI. Grids use special extensions to X.509 that are defined as part of GSI and discussed below under authorization. Without these extensions, some features of grids are unavailable. Currently, only CAs directly concerned with grid work, such as the UK e-Science CA, are known to produce compatible fully-certificates. Thus, if the VObs is to use GSI, as it must to use standard grid middleware, then we must find a set of CAs covering all legitimate users. We cannot expect one existing CA to sign for all users of all nations; the global, commercial CAs may not issue compatible certificates; the national science CAs produce good certificates but will not sign for foreign nationals; and global, science-oriented CAs (such as the Globus CA, now discontinued) have insufficient identity checks when issuing certificates. For any given set of CAs, the overall security of the combined PKI is equal to the security of the weakest PKI. Suppose that the VObs starts with a set of selected, trusted CAs which are GSI-compatible and which have sufficiently-secure PKIs. These are likely to be the CAs run by science-funding bodies in the industrialized nations. Choosing the core set requires agreements between all the major partners in the VObs and must be restricted so as to be politically acceptable to service providers. The core set of CAs will exclude many bona fide users around the world. In the medium term, the core set of CAs must be expanded to cover all possible users of the VObs. There are several ways this might be achieved. Arrange with the global, commercial CAs to provide GSI-compatible certificates. There would be an annual cost for every certificate issued. Run new, local CAs on behalf of the VObs. Initially, all VObs projects might have separate CAs and these could be made interoperable if all service providers in all VO projects agreed to trust all the VObs CAs. If some service providers distrust some CAs, then the interoperation is partial; this might be acceptable in the case of a few, special services. Users with no local VObs project would have to make arrangements in another region or country. Run one new CA on behalf of IVOA. Again, all service providers would have to trust this CA. Running an international CA to reasonable security standards is hard; it is difficult for users to present physical identification when they live on a different continent! It may be possible to delegate the identity checking to regional or national CAs. However, this fragments the trust model: service providers will not then trust the IVOA CA since they do not trust some of its subsidiary CAs. Provide gateways between national grids such that users trusted in one grid can be authenticated in a peer grid. This means that operations in the peer grid are done in the name of a software agent from the requesting grid. The end-users DN, if it is required for the operation, has to be sent by some other means than the certificate used for authentication. As an extension of point 4, dispense with end-user certificates altogether. End-users authenticate to a web portal using a password, and the portal passes the job on to the grid using the DN and certificate of a software agent. All the work, even in the home grid and PKI is done under the agents credentials. Option 5 is the only one that works in the transitional period when most end-users have no certificates. Therefore, this is the method used in the AstroGrid infrastructure, which has to work in the early days of the VObs. Option 1 is the simplest, both technically and sociologically. Authenticating requests to services: transport and message-level security GSI enables an agent sending messages to authenticate cryptographically to the party receiving the messages. This feature can be used either to protect the transport channel carrying the message, or to protect individual messages. Traditionally, web services and grid middleware (e.g. Globus Toolkit 2) has used transport-level security; the web services were using HTTPS and the grid services were using custom protocol stacks. GGF have standardized a set of APIs for making transport-secure connections using GSI. However, this standard defines only the interface, not the implementation or the wire protocol. The details of the security implementation are closely tied to the protocol of the data exchange. There is little reusable code for implementing transport-level security. HTTPS is not ideal for web services. It encrypts all the data of every message, which is an unnecessary load in most cases; the communicating parties want authentication and integrity of data, not privacy. Modern web services are starting to use message-level security, in which individual messages are digitally signed or encrypted as needed. Where authentication is needed, messages are signed or encrypted and authentication is implicit. In SOAP messages, the security provisions are put in the SOAP header. This makes them independent of the protocol in the message body. Code for securing SOAP messages can be reused for all such messages in all applications. There is an OASIS standard for this: WS-Security [34]. It defines the schema for including signature and encryption metadata in the SOAP header. There is currently no GGF standard for using WS-Security with grid services; it is not part of the OGSI 1.0 standard. However, Globus Toolkit 3, which is widely seen as the prototype of OGSA, uses message-level security in preference to transport-level security; it does the former according to WS-Security and deprecates the latter. VObs web services are clearly better off using message-level security according to WS-security. Message-level security is suited for secure communication with ordinary web services, and also allows interoperation with OGSA. Avoiding replay attacks: WS-Secure conversation If a sender signs each SOAP message, using the message-level facilities mentioned above, then the service accepting those messages is only partially secured. An attacker with access to the network can capture an entire, signed message and replay it to the service, thus posing as the original sender under the senders signature. This can be used as a denial-of-service attack if the effect of the message is not idempotent. To defeat replay attacks, the service can require a higher degree of message-level security as specified in the (draft) WS-SecureConversation standard [35]. This standard uses the context of messages to render a message invalid if replayed out of sequence. Globus Toolkit version 3 implements WS-SecureConversation as the default mode for secured services. (It can also use the basic signature and encryption modes if so configured.). It seems likely that this will become the eventual standard for GGF, since service providers will not be willing to lay their services open to replay attacks. However, WS-SecureConversation is not finalized yet, so it is unlikely that the current GT3.0 implementation will match the eventual standard, or that it will fully interoperate with implementations in other toolkits. Authorization Authorization can be very simple or quite complex. The complexity of astronomical data and IPR suggests that the VObs needs the more-complete kind of authorization. A very simple service may have implicit authorization: any user who authenticates has equal rights in the service. This presumes that all users are equal (and so does not allow different treatment by the VObs of, say, high-school students and professional astronomers) and equally trusted (requiring that all users of the VObs be vouched for by CAs of the same quality; see the discussion above). This authorization scheme is insufficient for the VObs. Adding one step of sophistication, a service may map each grid users DN to a local account. The privileges accorded to the DN are those accorded to the local account. This is the default scheme for the Globus Toolkit, which uses a local file, owned and maintained by the service provider, to define the mappings between DNs and local, Unix accounts. A comparable scheme is used in OGSA-DAI, which maps DNs to database users via a local file. This scheme works for special services with a few, privileged users; this is why it has survived in prototype grids until now. The scheme does not scale well to grids with many users, since every service provider must make local changes to the mapping file for each new user. The VObs may use this scheme for a few special services, but it will not do for general operations. If nodes in a grid are uniform, the authorization map-file may be mirrored from a central server. GridPP and EDG have used this technique with Globus Toolkit 2. This may be a useful stop-gap for the VObs projects, but the VObs as a whole is too heterogeneous and too decentralized to allow this as a general solution. It is possible to model users as a community, to assign access rights over services to the community and to let the community administer the details. In this case, the service providers and the community leaders agree the definition of groups of users. The service providers assign access rights to particular groups, and the community manages the membership of the groups. When a new researcher joins a community, entry into the right groups, made once by the community administrators, grants access to all relevant services. The OGSA security road map [36] for GGF specifies that there should be authorization servers and implies that authorization should be community-based. However, there are no standards, even in draft, for how an authorization server works in a grid. The Community Authorization Server (CAS [37]) from the Globus Project is a prototype of an authorization service. As yet, no production version has emerged and the prototypes are not suitable for production use. Prototype grids tend to build their own authorization servers. EDG has the Virtual Organization Management System (VOMS [38]). The e-Science data portal at CCLRC [39] has an authorization server built in. AstroGrid has an access-policy/community system [40] designed against grid needs but not to grid standards. There is also PERMIS [41]. These tools could be reused for the VObs. I suggest that the VObs cannot, at this time, make a sensible choice amongst the various, partial systems. Nothing implemented now will be a complete and compatible solution in three years time. If we need grid-compatible authorization code, then we must wait for the GGF standard. Strategies for engaging with the grid There are several levels at which grid products and conventions can be incorporated in the VObs public network. This section looks at the relative merits of the approaches. To help the comparison, the VObs is visualized as having three layers: a UI layer, containing web portals and data displays; an agent layer managing workflows, authorization policy, maps of distributed storage, etc.; and a resource layer containing services that give direct access to archives, algorithms, storage. The data grid is assumed to connect services in the resource layer. In all the following descriptions, OGSI would be replaced by WS-RF if the latter becomes a standard. M.1 No grid products at all The UI layer uses IVOA conventions. The resource layer has some stateless services and some services in which state is managed using WS-CAF. The resource services are almost all written by IVOA members; no services from the grid community are used and the IT industry provides few complete and finished services that are relevant. The agent layer uses WS-CAF standards to manage workflow. Commercial workflow-products can be used with IVOA resources-services. However, these products do not always interface well with the UI layer and are generally used with their own UIs; they tend to be restricted to special experiments. Access control is to IVOA standards informed by IT-industry standards such as WS-Security. The data grid is built to an IVOA standard since GGF standards are excluded and the IT industry has no general standard. All IVOA resource services have access to the data grid but the few utility services from the industry do not use this grid. M.2 Everything based upon GGF standards The UI layer is built to IVOA standards, since GGF does not specify how a UI should be built. The resource services are all OGSI services. Simple, stateless services cannot be used here. The agent layer uses OGSI semantics to control workflows and transactions in the resource layer. It cannot use resource services that do not conform to OGSI (even if the services are stateless) and it cannot drive services that require WS-Coordination. Much of the agent layer is supplied by the grid community for free: workflow, scheduling, reservation, logging are all areas of interest inside GGF. The data grid uses GridFTP and OGSA services. M.3 Grid services only as leaves of the service tree The UI layer uses a mix of IT-industry standards and IVOA standards. It does not understand OGSI semantics and does not talk to OGSI services. The resource layer contains a mixture of OGSI services, stateless service and services for which state is managed with WS-Context and WS-Transaction. Some of the resource services are taken from the grid community and are unaware of IVOA conventions. Some services are written by IVOA members, without reference to GGF standards. The agent layer uses both OGSI semantics and WS-CAF semantics to control the various resources. The services here are web services but not OGSI services. The access-control standard for the UI and agent layers is either peculiar to IVOA, or it is an IT-industry standard; in either case, it does not use GSI-compatible certificates of identity. The agent layer translates from this standard to the OGSA-security standard when talking to OGSI-compliant resources. However, it cannot drive the grid resources in the name of individual users since it cannot produce proxy certificate for those users. Instead, work in the grid services is done in the name of the software agents (i.e. the agent layer has some GSI-compatible certificates of its own) and some operations that depend on user identity become impossible. There are two data grids: one uses IVOA standards and the other uses GridFTP and GGF standards. Neither of the two data grids connects all the resource services, since the grid resources do not know the IVOA standards and the IVOA services do not use the grid standards. Some services may act as gateways between the data grids. M.4 Leaf grid service plus pervasive GSI and GridFTP The system is built as in the previous section but with certain changes. The access-control system at al levels is made compatible with GSI. In particular, users have personal certificates that are GSI-compatible, so access to grid services is not limited by the architecture. There is only one data grid and it uses GridFTP to move files. All resource services can access the data grid. M.5 Grid conventions rule inside intragrids The system is built according any of the four models above. Some resource services are faades for intragrids. Where work is needed on an intragrid, the faade service handles all the conversions from VObs to grid conventions. The intragrids are separate and need not use the same standards. Comparisons M.1 gets the best support from the IT industry and M.2 the least. M.2 gets the best support for science outside astronomy and M.1 the least. M.3 gives the authors of resource services the greatest freedom. This model gives the greatest chance to adopt ready-made services. M.2 and M.4 make the best use of access-control standards. M.1 and M.3 are at risk of having many incompatible standards for access control in different parts of the VObs, driven by the demands of service providers. M.1, M.2 and M.4 give the best coverage for the data grid. M.1 requires VObs collaborators to write all the data-grid middleware, and M.2 gives the greatest chance to adopt existing solutions. M.2 prescribes standards and products that were produced to suit the needs of science. The other models all use standards intended for business systems. All the models rely in some part on standards that are not yet final. However, M.2 depends on many GGF standards that are not even drafted yet; only the intention to produce these standards is recorded. It is hard to start building M.2 with the existing standards and products. Current VObs work matches M.1 and M.5. Altering it to achieve M.2 would very hard. Notably, all VObs services would need to change at the same time to remain interoperable. The longer that the current work is progressed, the harder it would be to achieve M.2. Current VObs services do not implement WS-CAF or WS-Security. Adding these throughout the VObs may be expensive when there are many existing services. However, all the SOAP-header-based standards can be added service by service without affecting the interoperability of the services, since the SOAP headers do not alter the syntax of the bodies of the messages. Therefore, it is feasible to retrofit IT-industry standards to existing web services. In discussions of the web-and-grid-services work-group of IVOA (at the interoperability meeting of October 2003), opinion was overwhelmingly in favour of M.4 and M.5, with marginal support for M.3. No support was voiced for M.1 and M.2. Summary of recommendations Web services Continue to use web services as the basis of the VObs. Prefer SOAP services to simple HTTP-get operations as SOAP allows higher-level features like transactions to be added later. Exploit IT-industry standards and conforming products where they become appropriate. Prefer these to grid products and standards if the two are incompatible. For VObs web-services that are in the public registry, prefer techniques such as WS-Context to OGSI. Consider supporting WS-CAF and WS-RF in each service if WS-RF becomes standard. OGSI/WS-RF and OGSA Do not use OGSI 1.0 unless it becomes certain that WS-RF will not replace it. Do not convert VObs services wholesale to OGSI/WS-RF; the gains are not great enough and the supporting software is not of sufficient quality. Do not use OGSI /WS-RFservices in critical parts of the VObs (portal, workflow, etc.); they cannot easily be made sufficiently predictable. By all means exploit OGSI/WS-RF services written by third parties, but only at the edges of the tree of services. OGSA-standard services are preferable to arbitrary OGSI-compliant services as alternative implementations may be available. Avoid coding services in OGSI/WS-RF until better toolkits are available. Look for alternatives. Produce library code that makes coding clients for OGSI/WS-RF feasible. Data-grid software Use GridFTP as the main transport for files in the data grid. Do not use SRB as the basis of the data intergrid. It is OK in intragrids. Use OGSA-DAI (or ELDAS) to move relational tables. When the interfaces become sufficiently stable, consider re-implementing them independently of the grid products in conventional web services. Define VObs standards for data grid operations. Hide grid technology in the data grid behind a VObs faade. Access control Use GSI-compatible X.509 certificates as the main way of identifying users within the VObs. (Portals can still use passwords at the system boundary.) Use WS-SecureConversation as the main authentication mechanism in the service grid. Use the WS-Security packaging for SOAP messages. Allow WS-Encryption, but deprecate it for normal services. I.e., clients must not expect an arbitrary service to support encryption. It is allowable for special applications. Open discussions, as a priority, on interoperation of identity certificates within the global VObs. Expect that full certification and interoperation will not be achieved for some years. Until VObs users have certificates, certify software agents to work on their behalf. Refererences Global Grid Forum: http://www.ggf.org/ Organization for the Advancement of Structured Information Standards: http://www.oasis-open.org/home/index.php World-Wide Web Consortium: http://www.w3c.org/ Internet Engineering Task Force: http://www.ietf.org/ Simple Object Access Protocol: http://www.w3.org/2002/ws/ Web Services Description Language: http://www.w3.org/2002/ws/ Open Grid Services Infrastructure: http://www.gridforum.org/ogsi-wg/drafts/draft-ggf-ogsi-gridservice-29_2003-04-05.pdf Web Services Composite Application Framework: http://www.oasis-open.org/committees/documents.php?wg_abbrev=ws-caf Web Services Grid Application Framework: http://www.neresc.ac.uk/ws-gaf/ Web Services Resource Framework: http://www-fp.globus.org/wsrf/default.asp Open Grid Services Architecture: https://forge.gridforum.org/projects/ogsa-wg Globus Toolkit: http://www.globus.org/ Fujitsu Unicore, OGSI adaptation: http://www-unix.gridforum.org/mail_archive/ogsi-wg/2002/Archive/msg00157.html University of Virginia OGSI implementation: http://www.cs.virginia.edu/~humphrey/GCG/ogsi.net.html MS.NETGrid: http://www.epcc.ed.ac.uk/~ogsanet/ OGSI::Lite: http://www.sve.man.ac.uk/Research/AtoZ/ILCT Problems with Globus Toolkit 3 and some possible solutions: http://wiki.astrogrid.org/bin/view/Astrogrid/GlobusToolkit3Problems Web-services tutorial at ADASS2003: http://www.ivoa.net/twiki/bin/view/IVOA/WebgridTutorial GLUE web-service toolkit: http://www.webmethods.com/solutions/wM_Glue/ AstroGrid experiences with GLUE: http://forum.astrogrid.org/read.php?TID=538 Condor: http://www.cs.wisc.edu/condor/ File Transfer Protocol RFC: http://www.w3.org/Protocols/rfc959/Overview.html GridFTP working group at GGF: http://www-isd.fnal.gov/gridftp-wg/ Reliable File Transfer service in Globus toolkit: http://www-unix.globus.org/toolkit/reliable_transfer.html GridPP: http://www.gridpp.ac.uk/ Replica manager service in Globus Toolkit: http://www.globus.org/rls/ Open Grid Services Architecture Data Access and Integration service: http://www.ogsadai.org.uk/ SkyNode: http://www.ivoa.net/twiki/bin/view/IVOA/IvoaVOQL Enterprise Level Data Access Services: http://www.edikt.org/eldas/ Data Access and Integration working-group of GGF: https://forge.gridforum.org/projects/dais-wg Storage Resource Broker: http://www.npaci.edu/DICE/SRB/ Grid Security Infrastructure: http://www.globus.org/security/ X.509 standard for identity certificates: http://www.ietf.org/html.charters/pkix-charter.html Web Service Security standards of OASIS: http://www-106.ibm.com/developerworks/webservices/library/ws-secure/ Web Services Secure Conversation (draft) standard: http://www-106.ibm.com/developerworks/library/ws-secon/ Open Grid Services Architecture - Security Working Group: https://forge.gridforum.org/projects/ogsa-sec-wg Community Authorization Service of Globus Toolkit: http://www-fp.globus.org/security/CAS/ Virtual Organization Management System: http://hep-project-grid-scg.web.cern.ch/hep-project-grid-scg/voms.html CCLRC data portal: http:// www.grid-support.ac.uk/ ahm2003/AHM2003_8_DataPortalHandOut1.pdf AstroGrid access-control software: http://wiki.astrogrid.org/bin/view/Astrogrid/AuthorizationItn3Final PrivilEge and Role Management Infrastructure Standards Validation: http://www.permis.org/ Appendix C Cost Statements  http://www.euro-vo.org/pub/articles/ScienceWithProtoVOtools/text.htm  http://cdsweb.u-strasbg.fr/UCD/  It is unfortunate that the grid community takes VO to mean Virtual Organization while the astronomical community understands it to mean Virtual Observatory. The confusion is increased by the fact that a Virtual Observatory is a specific kind of Virtual Organization. In this document I will use the abbreviations VOrg and VObs for clarity.  Year 2 Report Page  PAGE 22 of  NUMPAGES 91  EMBED MSGraph.Chart.8 \s  Data Centre Alliance Facility Centre Technology Centre P`uvw*:;^_`noH K ʸêʔʄzqfaOJQJ@@OJPJQJmH @@CJOJQJ0J5@@OJQJj5@@OJQJUj5@@OJQJU0J@@OJQJj@@OJQJUj@@OJQJU @@OJQJ5@@OJQJ5@@CJH*OJQJ@@CJOJQJ5@@CJOJQJj5@@CJOJQJU$$78P`Zk$$IfTl0 ! ]04 la$$*$Ifa$ `0$;*$^`;a$ `0$;*$@@&^`;a$ `0 $78P`aw*+:pqrs !#RUVXpstv    D G H I * W y  e N < Uz#a  ^`aw*+:p($$*$Ifa$ `0k$$IfTl0 ! ]04 lapqrsjZZZZZ$$*$Ifa$ `0$;*$@@&^`;a$ `0$;*$^`;a$ `0k$$IfTl0 ! ]04 la  m[$$*$Ifa$ `0$$IfTlF3qC"> t0    4 la$$*$Ifa$ `0 !#RUVXpstv{kkk{xkkk{kk$$*$Ifa$ `0$$IfTlF3qC"> t0    4 la    i|YYYiYYYi$$*$Ifa$ `0$$IfTlF3qC"> t0    4 la$$*$Ifa$ 9r `0   D G H I k^I? $*$^a$$V*$^`Va$ ? $a$ ;5%$$IfTlF3qC"> t0    4 la$$*$Ifa$ `0 * W y  e N < Uz#a e#  e#  e# $a$ $*$^a$K * V ^ x z {       E F ` a b c d e h i   ߻߻߻jUmHj6UmH OJQJmHjUmHj<UmH 5CJmHjUmH5;OJQJmHjBUmH jUmHmH jU@@CJOJQJ@@CJOJQJ7 . / I J K L M N j k   6 7 8 : ; < z { 45OPQSTUjUmHjUmHj$UmHjUmHj*UmHjUmHCJmHj0UmH 5CJmH jUmHmH>YZtuvxyz!"#@@A[\]_`ajUmHjUmHj UmH 5CJmHjUmHjUmHjUmHjUmHCJmHmH jUmHjUmH</01345]^xyz|}~  78RSTVWX"#$&'(opjUmHjqUmHjUmHjwUmHjUmH 5CJmHj}UmHjUmHjUmH jUmHmHCJmH=5~X(b-yaYNK+tU(R7i"O7t) \ !M!!!!("e""" #;#{###9$h$$$<%s%%%!&_&&&'='r''''(i((()@@)b5~X(b-yaYN e#  e#  e# AB\]^`ab  '()+,-XYstuwxy@@A[jYUmHjUmHj_UmHjUmHjeUmHjUmHjkUmHCJmHmH jUmH?[\]_`a~89STUWXYrsjUmH5;OJQJmHjGUmHjUmHjMUmHjUmHCJmHjSUmH 5CJmHmH jUmHjUmH8-.HIJLMNlm    *+EFGIJKbc}~CJmHj/ UmHjUmH5;OJQJmHj5UmHjUmHj;UmHjUmH 5CJmHmH jUmHjAUmH8K+tU(R7i"O7 e#  e#  e#   %&')*+STnoprst   45O5;OJQJmHj UmHj UmHj UmH 5CJmHj# UmHj UmHj) UmHCJmHmH jUmHj UmH8OPQSTUxy"#$&'(12LMNPQRbc}~jUmHjUmHjUmHj UmHjUmHjUmHj UmH 5CJmHmH jUmHj UmH>123567HIcdeghi !"./IJKMNObc}~jjUmHjUmHjpUmHjUmH 5CJmHjvUmHjUmHj|UmHCJmHjUmHmH jUmH<123567STnoprst # $ % ' ( ) ; < V W X Z [ \ u v jUmHjXUmHjUmHj^UmHjUmHjdUmHCJmHjUmH 5CJmH jUmHmH>7t) \ !M!!!!("e""" #;#{###9$h$$$<%s%% e#  e#  !!!!!!,!-!G!H!I!K!L!M!c!d!~!!!!!!!!!!!!!!!!!!!!!!""""#"$"&"'"jUmHj@@UmHjUmHjFUmHjUmHjLUmHCJmHjUmH 5CJmHmH jUmHjRUmH<'"("D"E"_"`"a"c"d"e"z"{"""""""""""""""""## # # # ###5#6#7#9#:#;#Z#[#u#v#w#y#z#{#############jUmHj(UmHjUmHj.UmHjUmHj4UmH 5CJmHjUmHj:UmH jUmHmHCJmH=#####$$3$4$5$7$8$9$G$H$b$c$d$f$g$h$$$$$$$$$$$$$$$$$%%6%7%8%:%;%<%R%S%m%n%o%q%r%s%%%%%%%%%%%%j#UmHj"UmHj"UmHj!UmH 5CJmHj!UmHj UmHj" UmHCJmHmH jUmH?%%%%%%&&&&&& &!&>&?&Y&Z&[&]&^&_&k&l&&&&&&&&&&&&&&&&& ''''''''7'8'9';'<'='Q'R'l'm'n'p'q'j&UmHj{&UmHj%UmH 5CJmHj%UmHj%UmHj$UmHj $UmHCJmHmH jUmHj#UmH<%%!&_&&&'='r''''(i((()@@)v)))*@@*r***+S++, e#  e# q'r'''''''''''''''''((!("(#(%(&('(H(I(c(d(e(g(h(i(v(w((((((((((((((((( ) ) ))))) ):)jc*UmHj)UmHji)UmHj(UmHjo(UmHj'UmHCJmHju'UmH jUmHmH 5CJmH<:);)<)>)?)@@)U)V)p)q)r)t)u)v)})~))))))))))))))))))))))** *:*;*<*>*?*@@*Q*R*l*m*n*p*q*r********jK.UmHj-UmHjQ-UmHj,UmH 5CJmHjW,UmHj+UmHj]+UmHCJmHmH jUmHj*UmH<@@)v)))*@@*r***+S++,@@,,, -e-- .7.s... /:/h///////k1l1|111p2g3z44446666677S7T7q78g|   |  +,            ?@@6************+ + + + ++2+3+M+N+O+Q+R+S+++++++++++ , , ,,,,, ,:,;,<,>,?,@@,f,g,,,,,,,,,,,j32UmHj1UmHj91UmHj0UmHj?0UmHj/UmH 5CJmHjE/UmHj.UmH jUmHmHCJmH=,@@,,, -e-- .7.s... /:/h///////k1l1|111$ & Fa$$a$$a$$a$ e#  e# ,,,,,,,-- - - - -D-E-_-`-a-c-d-e-----------.... . ...1.2.3.5.6.7.R.S.m.n.o.q.r.s............j5UmH 5CJmHj!5UmHj4UmHj'4UmHj3UmHj-3UmHj2UmHCJmHmH jUmH?........//// / ///4/5/6/8/9/:/G/H/b/c/d/f/g/h//////////6677I;J;;;;;;CCCCC9D:D F³j9U0Jj8UOJPJQJmH OJQJ jUj8UmH 5CJmHj7UmHj7UmHj6UmHCJmHmH jUmHj6UmH91p2g3z44446666677S7T7q789!:}:~:< <Y<$ & F a$$ & F|a$ $a$ 9r $a$$a$$a$$ & Fa$89!:}:~:< <Y<<<<=/=X=====&>b>>>>û}qe]TH<&   tQ   v       Y   ~"   H       z     /  Y      Z[|  |  |  Y<<<<=/=X=====&>b>>>>>t@@u@@@@@@zA{AAA,B$ & Fa$$a$$a$$a$$ & F a$$ & F a$>>t@@u@@@@@@zA{AAA,BMBDG'HHJKKKLLQQRjS-TTT?VlWWXYXZX|wtnf^[V,OQ<}  i}   } ({->-     T      .  O      9d!,BMBDG'HHJKKKLLQQRjS-TTT?VlWWXYX$ & F}a$ ($*^*a$  -$^`a$$a$$a$ $a$ 9r $ & Fa$ FF/F0F1FDFEFFF?G@@GAGsGtG[H\HHHHHHIIIII0J1JGJHJJJJJJKKLLOOOOOOPPPPRRjS}S-T@@TTTU?VcVlWWWXXXYXZXXOJPJQJmH jUmHOJQJ 5OJQJ5OJPJQJmH j?Uj1>Uj^=Uj<U0JjV;U jUBYXZXXXZ\]]__}a~aaaaaaaaacbb@@dAdg$]a$$a$$a$$a$$a$$ & F~a$$a$,ZXXXZ\]]__}a~aaaaaaaaacbb@@dAdgg(hijjjKmLmooopp¿}xsnhc`?i +l+7+8+++ g z"# P  ,'()*+ ~  ~   ~ N$XXZZ\\!\_____``|a}aMdOdmgngggggggjooppprrttuugyiyKzMzN{F|G|||||||}}(g!"INdÇЭ6mH mH jCB*Uph >*B*ph>*jBB*Uph B*phjB*UphH*OJQJ0JjkAU jU jUmH5Agg(hijjjKmLmooopprrtZuww $]a$  $]a$ #$a$ $a$$]a$+$a$$a$$a$$a$$a$prrtZuwwx7y8yM{N{||}}}O~~NO:;>7U~yvmd[x  -x  Hx  I Rx  x  x  x   #x $   ##> wx7y8yM{N{||}}}O~~NO:;> $ & Fx]a$$ & Fxa$$a$$a$$]a$ $]a$ $a$ $a$ >7UzԄ)*+,-fggh$a$$a$$a$ $ & Fx]a$$ & Fxa$ $]a$ $a$ $]a$UzԄ)*+,-fgghϐА12YƔ8 þ|vspmjgd  :;gHI]^>? Mx  jx  x  x  x  %ÇӇ ͊K`|78:deͬ}شjk4567nojy~234jIGUjxFUjQEU60JjpDU jUH*mH j0J UmH  56mH mH 6mH JϐА12YƔ8 !h$ & F{a$$a$$h^ha$$a$!hޣߣYZ9;b3KL˩̩gh(g*+ȿ}wog_WTsz  z  6z  uz   5z 6QRx  x  jx   x  ;x  bx  d   {   M{ TU F hޣߣYZ9;b3KL˩̩gh(g$ & Fza$$ & Fxa$$a$$^a$$a$$ & F{a$*+jkSTTU67k34ghqrc$a$$a$$a$$ & Fza$+jkSTTU67k34ghqrcwgopýƴ{vsnkU## Y t  w  zq  c23r)cwgop=-^n#$a$$a$$a$4;<#$%PQq!FjV^&/::/   HIBeOPQ#jI0JU j0JUCJKHOJPJQJmH 5B*mH phmH  5B*phjWIUj0HU jU0JF=-^ncdcdyHIJpq½{xroje`       DE            )*              JF  0"V %ncd $$Ifa$$a$$a$$a$ ci``` $$Ifa$$$Ifl      Fp #     t06    4 lacdyHIJpq~uuu~uuu~pkp$a$$a$ $$Ifa$$$Ifl      Fp # t06    4 la q`$$Ifl      Fp #     t06    4 la $$Ifa$ !2=FGntuvwPVWX=>Ŀzrhd_Z    9: z          !  '         bc  d  j         st  u  {  " !2=F~ytykkk $$Ifa$$a$$a$$$Ifl      Fp # t06    4 laFGntu~~~ $$Ifa$w$$If4Fk#.       x       V$    1l1l4 l4auvw $$Ifa$$a$$a$b$$If4Fk#.     x   V$    1l1l4 l4aPVW~~~ $$Ifa$w$$If4Fi#             V$    1l1l4 l4aWX=> |$a$$a$ $ & F$Ifa$ $$Ifa$b$$If4Fi#       V$    1l1l4 l4a aghij cV\yvqlgc^  Q           `   g         GH  I  O            " agh~,w$$If4Fi#                 1l1l4 l4a $$Ifa$hij $$Ifa$$a$$a$b$$If4Fi#           1l1l4 l4a cd[[NN $ & F $Ifa$ $$Ifa$$$Ifl      Fp #     t06    4 laytotfff $$Ifa$$a$$a$$$Ifl      Fp # t06    4 laV\]d0[[N $h$If^ha$ $$Ifa$$$Ifl      Fp #     t06    4 la\]^&'(`fNem&/º{wtnkfa\XSN  m          %   $ :   9 B   A Y  X    A   G               IJ  K]^&y(ppcN9$ & Fh$If`ha$ $ & F$If^a$  $8$If^8a$ $$Ifa$$$Ifl      Fp # t06    4 la&'(`fNempccVVV $ & F$Ifa$ $ & F$Ifa$$$Ifl      Fp # t06    4 la $$Ifa$ lgbgYYY $$Ifa$$a$$a$$$Ifl      Fp # t06    4 la $ & F$Ifa$&/^d[[FF$ & F$If^a$  $$Ifa$$$Ifl      Fp #     t06    4 la/^4:n%09:LUklm{xrojea\W  |       jk               %   Y    _  {|       5   d  4:nypp_ypp__y$ & F$If`a$ $$Ifa$$$Ifl      Fp # t06    4 la %09:LUQ$$Ifl      Fp #     t06    4 la $$Ifa$$a$$a$ UklmlgbgYYY $$Ifa$$a$$a$$$Ifl      Fp # t06    4 la $ & F $Ifa$)d[[[ $$Ifa$$$Ifl      Fp #     t06    4 la)*v}efgz{}ytojf`Z                                              CD  v")*v}efgylpppppypppyk$a$ $$Ifa$$$Ifl      Fp # t06    4 la gzQ$$Ifl      Fp #     t06    4 la $$Ifa$$a$$a$ z{yHppppypppykk$a$ $$Ifa$$$Ifl      Fp # t06    4 la EKFGH|<=>?@@bc"`X     L ½xpmg^R   w  i    5  o       <= n/    C  I  }~    z           EKFGV$$Ifl      Fp #     t06    4 la $$Ifa$$a$ GH|<=>?@@bcyppppykkfkk$a$$a$ $$Ifa$$$Ifl      Fp # t06    4 la "`X     L     /     $ & Fa$$]a$$ & F]^a$ $ & F^a$ $ & Fa$$a$$a$L     /      <   GHbcABO[dekzŽ{vrmhc_ZUP                  D       !    H     .      P     <   GHbcABO[d $$Ifa$$a$$a$$ & Fa$$a$ $a$ 9r dekzjaaa $$Ifa$$$Ifl      F\#     t0W$    4 lavvvXvvviLvv $ & F$Ifa$ $$Ifa$$$Ifl      F\# t0W$    4 la [\b78>Xbh{|VW]þzuphc_ZUP                                               V   h    [\b78>Xbipi$$Ifl      F\# t0W$    4 la $ & F$Ifa$ $$Ifa$ #$%YZ56 ST]kl?@@?@@efh{|jSUjIRUjPUjOB*Uph B*phjB*UphjNUmH jLUjKU jU0J j0JUjJ0JU9bh{|VW]rliii\irDi $ & F$Ifa$ $$Ifa$$$Ifl      F\# t0W$    4 la $ & F $Ifa$ ]'(.Gkii$$Ifl      F\# t0W$    4 la $ & F$Ifa$ $$Ifa$ '(.Gk(?/IJPoy 89xtoje[WTQN@@A              5  Q  WX k            *  :  @@A          ! A   x     (?/IJidi$$Ifl      F\# t0W$    4 la $ & F$Ifa$ $$Ifa$ JPoy 89-.id_ddd$a$$a$$$Ifl      F\# t0W$    4 la $ & F$Ifa$ $$Ifa$ 9-.?@@]^wx0S   !!g!u!v!!!"=">"""""C#R#S####=$}$}zwtq\FGV[\#$2# pH . vw +.?@@]^wx0S   !!g!u!v!!!#$`a$ $a$ 9r $a$$a$$%&Z[]^TU\]^4 5 w x y     -%.%%%&&&,'''' ( 6H*mH 6mH mH  B*ph0JCJOJQJ'jWY>*B*CJOJQJUph>*B*CJOJQJph!j>*B*CJOJQJUphjXUjVUOJPJQJmH jUUH*0J jUjgTU2!"=">"""""C#R#S####=$}$~$$%-%.%&&1'2',(-(P)Q)$a$}$~$$%-%.%&&1'2',(-(P)Q)e*f***0,1,J,K,b-e-f-g------- .0003335 5>57-8~{uro? q  7   i34HIlmghkl+ (())-))**B**** + ++ ,.,0,1,{,|,,,,,,b-d-..3/4/5/n/o//////(0)011%2&2'2]2^222222224444455f7g77j`Uj_UjU^Uj\Ujs[U jUmH0JjZU jU0J.mH  0J.6mH  6H*mH 6mH mH AQ)e*f***0,1,J,K,b-e-f-g------- .0003335$a$$a$$a$$a$5 5>57-8.8R8l8m8888899-9.9m9n999::s:t:: & F$ & Fa$ & F & F$a$$a$$a$777777-8R8l889,9-9.9;;;;< =2=T=7?k???@@J@@2ATAVApAqArAA B B5B7BKBBBBBBCCGGGGH;HIIMIlIIIIIYJkJJJK.K`K}KK굿0JmH jycUmH  jUmH  5H*mH 6mH 5B*OJQJph55mH B*OJQJphmH >*0J jUj4bUE-8.8R8l8m8888899-9.9m9n999::s:t:::;;;;<;z;{;;;;;;|tqif^[XEFl  m      \  ]    ;  <     V        !::;;;;<;z;{;;;;;;;$<w<x<<<< =U=V====>`^ & F$a$ & F;;$<w<x<<<< =U=V====>>a>b>>>??7?8?k?????@@@@I@@J@@@@yvnkc`X    -  .`  a    Y  Z    7m  n  E  Fj   ( )!>>a>b>>>??7?8?k?????@@@@I@@J@@@@@@@@UAVAqArAJBKB & F$a$` & F@@@@@@UAVAqArAJBKB8C9CCCCCDDDD@@EAEEE!F"FqFrFFFGGGGƾ|yqnfc[XC  D    4  5      A  B            R  S KB8C9CCCCCDDDD@@EAEEE!F"FqFrFFFGGGGGGH & F$a$$a$ & FGGGHHWHXHHH?I@@IIIIIJJNJOJJJJJKKLKKKKK)L*LLLºxumjb_WT&      i  j  ,  -f  g    +  ,u  v  ]  ^     k HHWHXHHH?I@@IIIIIJJNJOJJJJJKKLKKKKK)L*LL & FKK>LpLLLM#MMOOOOOOOOPPPP2P3PDPEP-QAQOQ^QnQQQQQRR"R#RRRSRoRpRRRRRRRRRRRRSSѻ 5OJQJCJOJQJmHjCJOJQJU CJOJQJOJQJ5CJOJQJ5B*OJQJphB*CJOJQJphB*CJOJQJph5CJ5B*CJph5B*CJphmH B*OJQJph6LLLL mB  G        -)     G   H           M   &fhTk`lm@@op rH{k{gLJƗ$` & Fdd[$\$ & Fdd[$\$d[$ & Fdd[$\$dd[$\$mm?o@@oho`pgpppppp r rG{H{j{k{~~|~fgyƇLJЇ?CŏkoŗƗov#$_`{dejk'(56NO\]0J2mH 5mH mH 0J3mH ^ek(6O]`y`x$dd$If[$\$a$ & Fdd[$\$d[$dd[$\$ & Fdd[$\$(6O]`y`xyXk97¿}wog_W!      ?                     ]    x   y     ~!_`xy,4RZ_`abcuvxyWXjkx|89pt66mH  OJQJmH  0J35mH  0J5mH 5mH j5UmH 0J2mH 0J3mH mH RxybUEE$dd$If[$\$a$ dd$If[$\$$$IfFr q? 06    34ab bUEE$dd$If[$\$a$ dd$If[$\$$$IfFr q? 06    34ab Xk97bYWYKKKK & Fdd[$\$dd[$\$$$IfFr q? 06    34ab 67&9:de '+-.013468;<?@@CEHIMNQSVW[\`bpqSTlm 0J35mH 5mH 0J3mH  OJQJmH 0J2mH mH Y7:e -$dd$If[$\$a$d[$ & Fdd[$\$dd[$\$ & Fdd[$\$ :e -.1478<@@DEINRSW\abMqTmÿ|wspjga^X ]  {                              ,     |  j  "-.147](MMM$dd$If[$\$a$$$IfF  ```0 6    234ab 78<@@DEINRSW\r4bbbr8bbbr<bb$dd$If[$\$a$$$IfF 0 6    234ab  \abMqTmb[Y[W[Wd[$$$IfF 0 6    234ab $dd$If[$\$a$Rkl!3!$J%%2&&'(w--D0O01%194T46ý꥝|vsmjda[     $X    b     ]    5   D   U v#Rkl!3!$J%%2&&' & Fdd[$\$d[$dd[$\$8<,8HM $X[_b!$epq#*[i=FQRklIXXb  ! % TY0J2OJQJmH  OJQJmH 0J2mH 0J3mH 6mH mH 5mH V MQ!!2!3!!"##$$I%J%%%1&2&&&&&''(((((())))**Y*[*J+K+++++v-w---C0D0N0O011$1%18494S4T46666y8z888889:<:::;;"?)?@@H*mH 6mH 0J2mH 0J3mH mH ]'(w--D0O01%194T466z88@@@@@@$dd$If[$\$a$d[$dd[$\$66z88@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@pCC`DpDHHK/KLL5NRN|NNNĿ{ume]6  ^        Y   h                     < &"@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@BBoCpCCC_D`DoDpDvDDDE EEESFaFyFFFFJGSGGGHHHHHHHIfIhInIII5J;JJJKK.K/KKKLLLL4N5NQNRN{N|NNNNNAOBOuOvOOOP0J2mH  0J35mH 0J3mH mH 5mH \@@@@@@@@x$k[$dd$If[$\$a$ dd$If[$\$$$If0  ``0 6234ab@@@@@@@@@@@@@@@@@@@@@@pC,zjpzjzjadd[$\$$dd$If[$\$a$ dd$If[$\$w$$If0 0 6234ab pCC`DpDHHK/KLL5NRN|NNNBOvOOPQQQRaVbV~V & Fdd[$\$d[$dd[$\$NBOvOOPQQQRaVbV~VIZJZdZ ^^____&f,f~iis tt?vEvW{[{vS|vpjd         K    B   x  Z   $PPQQQQR_______``b bb7b;bEbJbQbc d%f&f+f,fffffffg gciji}i~iiijjkkkkpllllpApEpPppqssss t ttt(t.t>v?vDvEvvvV{W{Z{[{k{o{}}uv) 0J26mH 0J2mH 6mH 0J3mH mH \~VIZJZdZ ^^____&f,f~iis tt?vEvW{[{vd[$dd[$\$$a$)-8?!RS59SĈ,0^a EFVWƝǝQR34DEMNmnszСҡSTYZNO0J5mH 0J3OJQJmH 0J2mH  OJQJmH mH 0J3mH XSFWǝR4ENnTZO4 & Fdd[$\$ & Fdd[$\$dd[$\$ & Fdd[$\$SFWǝR4ENnTZO>U^dhirㆀ{xspkfa]X  GH  L  R  [44r 4 4  bQ  L   ]           9  "%P=>|)TUhimqrvz{~ůFGI$,#$)*ڸ޸YZoq|z{Z[0J3mH 5mH  OJQJmH 0J3OJQJmH 6mH mH 0J2mH VO>U^dh$dd$If[$\$a$d[$dd[$\$4 hir{]lMMM$dd$If[$\$a$$$IfF9a  ```0 6    234ab r{$*{[IBC_dijľ|xsnie`[                      89    ~  2"c          ,-  5  >"$*{rigeieie^gd[$dd[$\$$$IfF9a 0 6    234ab  [IB$dd$If[$\$a$" & Fdd[$\$dd[$\$LP`d9<HIJ67?@@BC^_cdhj /056:<ACGIMOPfgY0J6mH  0J5mH 5mH j5UmH 0J2mH 0J3mH mH VBC_dibUEE$dd$If[$\$a$ dd$If[$\$$$IfF  06    34ab ijbUEE$dd$If[$\$a$ dd$If[$\$$$IfF  06    34ab bUEE$dd$If[$\$a$ dd$If[$\$$$IfF  06    34ab bUUE$dd$If[$\$a$ dd$If[$\$$$IfF  06    34ab 06;<CIOPgZdjswx}xsnje`[                       " /"+,  2  8  ?@@  E  K  ef  j  m  vw  |      "bUEE$dd$If[$\$a$ dd$If[$\$$$IfF  06    34ab bDUUE$dd$If[$\$a$ dd$If[$\$$$IfF  06    34ab 06;bUEE$dd$If[$\$a$ dd$If[$\$$$IfF  06    34ab ;<CIObPRBB$dd$If[$\$a$$dd$If[$\$a$$$IfF  06    34ab OPgZdjswb`^YIIII$dd$If[$\$a$"\$"$$IfF  06    34ab YZwx  PQVW[\`b|EFZ[wx'()fgGHt z ['^'a2h2w226C?Ckk 6H* j0J UjCJUmH0JmH j UmH  jUmH 0J2mH mH 5mH OwxGt:**$dd$If[$\$a$ dd$If[$\$$$If\U ````(0634ab= 0 dd$If[$\$$$If\U 0634ab$dd$If[$\$a$ QW\abF[x)*efRcR:{vpmjd\     }99`9 &   s O `   !"        HI  N  T  Z    ! =0 dd$If[$\$$$If\U 0634ab$dd$If[$\$a$QW\= 0 dd$If[$\$$$If\U 0634ab$dd$If[$\$a$\abF[=;92d[$"$$If\U 0634ab$dd$If[$\$a$x)*efRcR:o)0 & F9$a$$a$$]a$d[$:o)0I#MK3^Q. bAſzrjb  -  Y      V\ Z 5_9R de/w    &0I#MK3^Q. b & FA,&    / k XOX0ABcDs & F & F & FA,&    / k XOX0ABcDsE U!W"X"o"##7%&'''º~{xuroi E! 3-q- 1    <     / iSy]K(sE U!W"X"o"##7%&'''C((])))))**(*C*r* & F'C((])))))**(*C*r**{+,;. 1 3 3 3P44444575M67999Žyqifc`]Z"Qh    <  \     [$  S  n  x            9S r**{+,;. 1 3 3 3P44444575M679999: ;a;b;z;{; & F & F99: ;a;b;z;{;;<=>?@@AAABB[C\CmCuDDEE(EpF"HJLNPIQaQaR TT+UUSV|vnu    R=  LGw I   v@@ ({;;<=>?@@AAABB[C\CmCuDDEE(EpF"HJLNPIQaQaR T TT+UUSVVW^XXYgYZ3\]];^^^b_c__`bdgik\ll & F & F & FSVVW^XXYgYZ3\]];^^^b_c__`bdgik\llnpr:sWtXttuwxz-|ļ}uroifc`]Zz  )c      {    fk      j % S  O    #lnpr:sWtXttuwxz-| }}@@}~$ɂ ݌[ & F-| }}@@}~$ɂ ݌[uJʑ/0Lp7yÚ];~{xuroV: ]z f"s EF+ c9 UM B$% JK+*[uJʑ/0Lp7yÚ];<s;<s$HIUf>s`{|=ݫztnf^             ?        xJ g , }E( 9x"$HIUf>s`{|=ݫ & Fh^h(^CqrK\]^_`an ^`  & F & F & F^CqrK\]^_`ano4jûzpf\R/  /  /-  /\  /   /  w |l'[ 6    d         5    qr89tu{|~CJ j÷ U#jԨ: CJOJPJQJUVmH jU 5OJQJ0JOJQJmHj0JOJQJU 0JOJQJ jUmH j0J U6&no4jZ϶gܷL޸9<ɻq// & FZ϶gܷL޸9<ɻĺ~tj`VLB8/  /  /%  /g  /  /  /(  /o  /  /K  /  /  /  /  /  /  /G  /  /  /  qNĽ"jĿ3PQopq7ĺ~tjggeccaae/k  (/  '/.  &/  %/  $/b  #/  "/?  !/  /  /  /r  /  /  /R  qNĽ"jĿ3PQopq78$a$$a$$a$/$a$$a$$a$- 000(. A!"#n$8%Sz T3K J FȩXBl B63xVkQ)- Em(M#EVbA*Cm@@EOB.z(;lm= |vͷ& ZU\q/MkQKh|C/,^ZGGŽٳl0JȠ&%C(|(v! }?'-1=P{H+:, Wwewq߭!{>Q?.= 7w@@҇Oc2e_eToxϨd\\̟xwR[3ho_U|VLK|~)s~Hmz ߖa㩉 (?dsjHh2:1*Kb#.i;,cdL+V+"Uc"؛z)6Pl✶kS)fH';7۔߮a㣉 sngC-fr%J1n[" ^;I7к[Eū!&h;1ʳMqtD}"|C@@5 _Ml8j'_<s[O涞m={X,L][],Ɠ 5l]ÔذQbȧ)G qfn?Vo?;z ."ͷ#ũS"UG+S#FPmrLt 9-jQJFIFddDuckyPAdobed        s!1AQa"q2B#R3b$r%C4Scs5D'6Tdt& EFVU(eufv7GWgw8HXhx)9IYiy*:JZjzm!1AQa"q2#BRbr3$4CS%cs5DT &6E'dtU7()󄔤euFVfvGWgw8HXhx9IYiy*:JZjz ?v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*Uتk73%4DDAəTW]O'rEOq~Q,?*\__tqW]?(rEOq~Q,?*\__tqW]?(rEOq~Q,?*\_u<q;R{MSI4{FT qUx匲ЃLUv*y~W^i&[} 8喅#N+A*q~Q,?*\__tqW]?(rEOq~Q,?*\__tqW]?(rEOq~Q,?*kYumcc[R ;85%Y*G,ř@@]v*UثWb]v*UثV*(%RN*\_u<qW]?(rEOq~Q,?*\__tqW]?(rEOq~Q,?*\__tqW]?(rI{Oմ=RYҮMNxm 3+QSUت͵/qwqbO3E%1Wyr?q!ſFx濧5Ga>b?:T>4[EK5&sn_F*EF󿘹G7>a=)XZW~u?/ߒߞz /7˗UzuX܇89Z@@U;^`+2yV/C?"al_P8q?3?Ykcث_8 s?ww oO4,ZpcxQtc7=9~c8_C~umU9^I*?7kyOj#^q:}*i*;пsSEE6Ww߄bVYw淗T3j^C֐/âޞsjǭyw_=M^͟ğ3q?FLx |ޘኽraǕ|գޕ{ԡy@@1VIv*UثWb]v*UثWb]v*UثWbRkW d+NbBK$2dcpB)nY21%XxS{mky{>9Inxfd:QLYJ?o:IC6n;FBdNgX }""lgN^id+k@@[d@@1$t?紟VI_,?w#[/NGHWbs-`4mR5kފJ=Cd'а=yKZotk")hBáF@@ }3U欞vPjUs/ՅYGUDYGl&NE?GCfxpגE~YeHPR"h=6&קHB,;}P漺e/PsZ%5᠋(~f泧vz|O\J7Vbe${ubd}-ٿ2a܋=<|Ϣw7roqsq!pef.2ԃP \ a/+Fu%ڱ)c6:9:LNTnmB{2k0h>rCQ}r#,@@I> Ea%ra>{3ʿ_$-<ե@@<VJN6W?,BLa}+qy[^̏=>x\]i{2\NRtoGZE7#/yCT=;˿(~+ ]>̊$U>!#8lq@@_ BTN~fSмg{y$6Ykz-"!b_R8ݾ7Veq1Ha1|/~d~~JV2] -Ŭ.+T~ḷL8C&LG=/ѷ t,-FQ-/qrcpf;ukTҤ27O#Zɿh1a4~OU?%$k:<{Zmv2Zzӓs\ɏŗ%~V+,I<<פGlǬu=%n}:2S2CȿߛSH_=(壿H"/7 RN8%"dS gAc2Pޔ׷O j9}qeW80t(!cH" F6AQ'>('T5Ž[89uo;^ &nZt7d}XnśoGj~]VR+FnTPonܿ#uO._KkMNit&ڼdpHfTI4mߗ7УPk.4`PJVQ@@)F=U<v=TSY@@CyߘקQhޓ*(8q5-?(#?-}komRu eRQ!F~+@@W/X 7_O0OWoec][ۢ1#6DJ((Hڹe#yj~_^}k@@;ҵ9^nsi |e2 ";E͓ycϡ[^Iu}:Ien`PZ9-9.duLO٠cy3[]>Ϋ&i$9F1P7m FD^lZZIaS*m,[3̪[ccM>,Mכ+Ey[?ʴ=Ua8('NlwOa֭5 . ψWA3zQ%̆z1yk^ЭZT\4JTEb UTPA]"9y;//|f5:[4!+/]~G"`M['ӗYDƀY9~rO9yYnf~4M1njcIܞٟ;W,&4,;Xf^ /R?32rhB^@@>Fw/F%)zUGh+:&J$U$hBa8kᖿИem&`/?k1[w XZLVBa8kᖿИem&`/?k1[w XZLVBa8kᖿИemV/Ÿûߐ&(1lVզ*ƫ͏7s'㶹npZ_.142^Riw.x|E BU*Uثǭ+rcO̟1+vMgZ)2Yv!ٝ\ A/r>*q/p@@4E-΋SAH!lYy/WRzqpp}N<7핸B:b?L? ^2b_? p,-+n05yp_ۿL? ^2b_? p,-+l;pq͟巖?,G}];{3V.ln#j:b]ˮC.坹ic%GJ:⯢1Wb]v*UثWb]v*s:O<)u8grGS~R]K䄶2 K BPjV>Vޅ]Gy;W:--ƱfqWR91N*Иem&`/?k1[w XZLVBa8kᖿИem&`/?k1[w XZLVb)<8 llԯJb-4M7???G8!u54 z޼Эe#~gCм ˿} )ⴶB'~'bzU 枩&87uꟚygɐ2-`kV$Spb=9q??',?(g~zkO5˽?i w㊥VǽFuϹ禦0|תjv!;bAҿ ,IkOʯ-On5nT<{a'09Wln>qvTB2cFwVP),nG'7_6Fe~4L?ޗ7vOtIMuy_t)?w 9(WhwCyѥ[CMRwz*?]O"^?z=.?˼/[{_iexV^Kw_7/ѭYy'+O}k.~V~Kyco/'#rq~ho_id8Zk~h5?#]NлQ}+O1]A/9lOit~^}},r~a$zW$_z8<2gqCogu+mY'Fc,"oǪiZOo,ڥbli/׭Wl(K_nc=kYWCO\[J/4.||)Lblnsـ+k8Xjɵ_-]E={ dѮɊy c ޻W;W8cɉ~g~ZSi|z&FuS$;.>'Ikl-zFf) kVqI=mrpMh Umg~kMr`t#,N|U[_^]-Z bfߕpΚn ${ǹq|))J9#ekpjy]RN&P ӳ؞+?-_KijfKItvqRa}sSgto4DK,6&Ȅ8q eC/O,~h~_y_h.NƣQOڵa= $b\L|Hܶ}nmzS b͍͵휭mye,ww X:8>!8[[G9i~R6n=z S0 %tvYGs*hPzukqVԲ:Hr*|U?,U E:7ww+ tuYU M!w_(Aau>hS9v1i]G2J# ԃ:>HK 7|曠XүFeߩD5l\|3ÛwwR[H[m*FG$eɣyn o-~oy˚y_yrWKKy]c.s0jhD fAz/|o'eƑ-[%U'N%G6j&AH5{o+yz'S.|P _<Ma~O!Eխ :`,Vd?&R|2jbyӓE!gzi7ma/]wW HaA4#('O):"q52:eoo[k_DVP#ڬ@@ OI94W 2y ΞRa|}7-D-Ē0D* ʌ ,r~r?$.˘-<ȯiam+ēFhb$؃X̒Ly+[Y~dʿ>QӒ7S1ۙV 5%-]eav$K/3tzWVw]-{y?.Tud#xzvd>jM͟lƖ1o4c Ml|FA9KK |1M[t`gӭbUjGʆHϑprb??B?.47qqQkuri5xƭYlęgC \GZnk4}?4irEvVOL?|8-OOɟ1ZywT굴&c[$k@@~-jM8i7]E[{-mYӌ(+olʆHϓ ?N\kssyvՇcrvI/<>iˀ9h p9% :> <ӣ3Bf x1YeC,gˆXEO'(V Ү>q0/oZ6< tF u2`S,{s5]?qrFN_-G-?\yrZ x}o-NK<&u(X⍵)H;U!8͹q q+9yƏUǩˆդ3joQP! V"r#roo#N 7]ɿ*MqWroo#;UܛGw&v87^8:U֥z`Lz'H^WSALXG=S(s*=t(zʝSF]> gٕ'[[;uGw&v87]ɿ*MqT-e{j_UӠ؅T߲pIA89}J4Fo9y]U]2bۆ8_zr.8""G~szg|U8ã[Utsi6լ0 blz!1$u;Cr+?'[I˟X_Ҵ$jl 1TjYB1;+$4J(m4%!X0!N1(r+Cɧ.xGo.Z{TEs"^@@!S#4̸b9[#_S3y氯^P}7C$e`pG K,̖QY;PWb]v*UثWb]v*UثU+f-Ƌ_e݁]@@<$G"*QwM_0Z!uXޫq}eRѾ:o+6|9!ҿ1N#X}.B /ƞ[ߕ~l]&5g[]wNEaxaz!x,Byf3ʯο>hm75?O.0m4AYjhuykv*UثWb]v*UثWb]v*UثWb5nتKjA\(ڲdH; h?K䀳 28>xAbBE%_$ƒt`Tu #8mm۝7[D%V_§["Erf X~ii{jSta(%l)/ Y>^:AW2첁?2b5"@@^JsXR;,}emr0m=k[JŠ{/mmm]\ѾUވe9!7%?wGՋ[,^xA&3#2?7\V\\'ru~.\VME~a I?,Ϥj r]PIv{99mɪ{)N ^5Qyy-,j._D,?V) if96;E%u />it埙G;3ܐ`7=ړ(:ُ6@@='ÿ:)n,|qe 2IQW͸1V7MwqdmpKRVXIt )?d^QEߐ:VdL}D,Xi2pȼOr̝r+y{YMK >4*|arP'n)EQGZeh{b_󅟙QSH 'ψb*jv* !d`10s._oiڴ\+< IR9<3^qx-ޟu^[Hʄt*Co#\ry;ҷ[C$&>2rL𗓑 \rՇn)Y6Fqwh@@U|Nb(Z"3? oW|ο.q^*\FgdT)4H\}:kɣ|qƏ!݋ֱi-.;]q #I*:?/]6V>g>/y'.}H(BI$t5%9=%ͷtGhUڤlíKQ0ˣ$|cί&I&]kv=[C?^X2xHd4%Þ$z|CdƲbޜ_<^BIǩ6%iG[Ԗ2s[HV3,rI!x9êCDQH:4/5k~eSEWoJlG'4!j yEQ3`W?L/5K+`d:>nQk@@ȿʎhK=>H /"6-J,he*_P| )]p_ߒ~S&Wr>wxg}2Ӊq $Dҧ12`0{9u1hg||$6ߥKG 2FDrE]`zsDlQD<=~nyK>MtE攆xUeG4eȸE<~Xދ%y}:) n4㿩lB0peI~EI~wkIo"O0ZBڜZΜѕ'8bH-Sqypbv85>)#tr6.yJ{|+$1##;v/lS❎oɯ˿K'_S6&ʦfG$eȺ9_~uwNxa~VzMn)@@Kc w$r#HմqˬĒ[4R R½80i/A<_kZ)ˎ=U2A- ;~ Y<>cu|nG;ߙ?iU󏚼 ~kI ~̱FDHQa ^`gϓ-u .5/0[ƟS0GAi(eF!GBd -><2 ?;?%yOȗ70sKhorЖc Uj;o\,1͞|^0O<~Tb~\J/*^)=We#vs({A䌹YdslϏŏ O'-wu_:y^B#Ef^ٝr.xaij>sjN$lhgt#$Eb ?R|գG)ykHZ2(EdGsznsk:L280~VlX]zmڸZF V[Fo 0G<)顐^2GߗuFO.hW3 YP A:A9rpgP5 [?"ߞ?Ly_~aVf ?/dtJ֗b]v*Ϳ-~X>|ӑm6eںӦDIOl,8M2xsr+ɯyskK?;~L05!R RH2O;9wlHFn5_G̚MktѾ%{yՒ"ЌUXWb]v*UثWb_/\d]y~[B_?ߕ([m[^?TڪUXrHY~cO=7I_y7˰YEy,*#EI', Y~&jƭ=_X/&/5usdO#dUxE:<3&UثWbYtߜ^Oٮ6e.c/;]>Sk]LW{.#?D???9H5$:h~^U_%Z1E*yd%[lv7q17=%i1??Zo-Ă$֯"UrZz^M_?-w\$ q!`n<2pp:Lyk뫋뙯oo$in.Y՝f'ĜY$T0ثWb]v*UثWb]v*UثWb]v*U?nmiu#-uO+J a55})ZhV)˄O`K~y?_󕿓_ys+WtuUu{{IGC𱮾Q14]&&,(!fA"#9&4k1E&fY~͇vcd Yk,zf| Gl2N&D}aHx%9b`ʄ+)Ђ*S*z?OthԻuAC`Fbr΁Go2[TƳyZ6ږ1.WC]He≠ŇQ14X&4kwH٢6hjt 1CJ}>r{ӊUS0[;fSvx:NynGE**wH m)*ڸPX]ַ3Gsgr4rqyr~dEa9'8m(IIox,.jߌj?8~%t.'quN=g:b_{Yu*S^A}a(ڒ۸+HELI0_ɯ&~z*{ W˰è)^/x^eZLLKԎO1Z0IJ^*~qDE|zx˖6=\wҰy0~xg` 0*a*?)|,'×BeyoߓyY;MRM.[iR[9 rV80h~P%α_,}j:YGյ=9Xzl$$0Ua"Ԛ|C4Ċx26<{m~k_>Qo8nyylяY8_o*kQervp; d˓alPzג8Gi.m~>A#UQ08N D-c~i5 KK"mZY-,eH%zw1:c! hg\i渭GEg/KŏOY=4O-'{O;)F=xqM~t>ƽ<91qboĽogw`\5 KVJalenҜsgf._35ލyr[rIo'o,Yc*j")‹FrN>{47SU r63Dq%w`zs4Te_r?sz<tF3!cr 9)ɜN5qiN9|{9/>X󶩢j&kYK%s$dajIRC: >z:R^xjH+G-<A?͑'ew?ŏE{.^A9\9ˎ?9>YUʸbÛ_3q̿W>c,,~ӵAr&Xx  ]Wߞlt_mojm m B _N( de$=sw/c1yKFЗMod'sۏ[!{-_ͬ;*yɗֺ[OsuTxwO&.{c?<3;jcol- R͛ZY4dpx͘L eӜr$7|jo/8@@.}N^,xeXv/$ TP㙱ߗݒEkhQL}):4ؙZ)׏y8XŽCTzNkyԹKP.84{U ǴN Yte_WZ'P1jNYLӭ`G5VBU#G.Op?--m'\ѼŪ^O>e3)Fe?թFT8?KLywG5~aC7.Or13@@GF?%|g^W{{#ok2V[f> Ɵr#4ᴃ9iʿ%/'d󗞅Pu;J%,PQ5G&?@@xq&\ߘ?|ՠkyAo4O0\%ƣg3F9u,MU3LA]`'W^_UиȒ!=/17O8u$-L2IV7!r\Ɣ2?]i/sgӭ > 2=6lc뵙x9e8N]v*UثWb]ztߔZV]yIܲqM{ >>('K~E{9a[<~PI$YC}iM$ Hft3^'KRٔ0 ;P~hyo_^R|èX3Ìґo*N?N*|UثWVri?wI_yGsK:VWjvE:&TʰoyoJ\iݿB{G4v\O>WBq0 A؎6.UثWb]M?3Hh&q[*|UԿ0:fQ_{a-89-*/cOGٷ^eI[qFcoWb]v*UثWb]Q99{_?,'ͷMN.FRH$b;Ǚ9WFF_$M$M#4O4,w%'6Nfv*UثWb]v*UثWb]v*UثWb]v*Ug7瑿2|uw|lomjGZN35">!C79zL3榑}zQ8 󝭺گYRZAqs53SlLԬ57O4V+:#9He`F*]v*UثWb]v*UثWb]v*UثWbQ*IC\UJkx8QI,L+|pJ0l.4-;{{-AUeFnc?kcñInl$GXHJK%p'`)F*ݰl*~JhΩ* Hj;˽eR]M9eR]-5)y'=7s/o{0N9x1|rP ,+@@_X&j ݠvG%\׹2Z da #hf2>򿙴mO(y$}L4C?ٕz?UFTAFBb;Rvַjn,'$麚TH.Ě'ļKOjFK2Q{KVkKduG|yۓ>;Ea (ҁCuh&\|gʡ>o/yjgX{ FdnAe1M-_a&]Y5% <-OR),>B7$P;ʚw0|ǥ1keTrUJf!#T\c9nG|ʷ-}ߓ?qR^xyjk/t_焒G rxraE8J'0z7Wn2Ϗr?|=-e[Il+\QO2$WǓ>ȖP:m >xOl<8V' /?]ۘs&Y+3|# ⏛^_8 \GQ_=yAW䏙]oq{j%n`c01$`?wߖ{8.OM2+UGlɄ 1`Y6[>W}3_~`R n=NFP$qvoW``P\_RXl z -;m>_y8 >oԍQY J=X7^*eYq9l~O&\].:Rգ!i!aFM-yKT:u2^cqlx\LcwFsz꥗/mGGm |iolQ3J-.&F)s"|! .jﶛT,>^\ PQRf8xe.LSI.5|8䤸O4I .;;(|A&ɗ D-,&.ǭ>iI?qfr_2!2\~\_%<OKRm]DZ6>Z\g׼^oImfe@@yup|N`4 e-鉋ſ&.֠(M3WHw1{?_.e h_h0/LBXY.2糋I8>du.^hZ֛!uo$P:Rw/ AۛOߗqߚyk1Gge]@@I21hrZ'5ȋx1O{yƥ)89 eq~XkZeK08Д _'i58oGg_@@YW5_)= A$?d4g˧>|{{qo#j/k >V\H\vu lk8y`7?;E7[v0NC5Źuڄ(hk3\B]_z?GIv+kSճxn*21.NLR=qOnnGѴRr[HVHhњz2TS+#vHc}?q}s{NK" Xnu*she wZf,1Nc03 ON>obլ.yfkc'l ofmͭeuBfaNv1;r!ەkvT'>>ys0?(lo4(kT,)rWb-'uOON3}CGȷsVK_1n,± hRJS*S?hg=JkK/e|jbdAZQU/*jl_ǘ|%5Q.}G6^sg|qK̎fZUثWbYgG|%ĖZr-\BJ1z2UQ-|9cI-}.̟%yk_h|qy@@ON2Wk<}>?'D,.\7`,7 |@@=W]v*UثWb_1\~p꿓Z"7ߚz_2[cofQNjHM+|]'(]ƣMKjZ;Зgah[V3Ϛ< _5ڦu-ƟDdUxE:<3&UثWbY/Ώ%Y\A)8-oU/凙/dW=niڲz%}@@gRz6ȳ}v*UثWb]v*UثWb]v*UثWb]v*PŒ*cfB*h[OTHX(䘔ՐGuKV,͊:$d=HO٘ GbcI}E隥Dޭ5яkԩq" '.i/t6WVYTW 1.{94gCLj>90mJ$aS8ߜ$QkL"I]yŸSo{uQo&YQ=%gQOgЬx}cM  9fhX(Gؕ{ F<;LT5o F ~@@=>ˁۿQFv1Jw : e6q' yAhz֕5{27ux7ĔH4X}b,|]\ ]*.4}=d_`S' ً'z_+1Escw֬>$9>#y Jc^ۛ#/zu̇m:8mq:տ*|yeAk8PCYI_\<+ѾR! rx~Y~F*I,b+C%RL|z;b<ڳ>OڹkHA9vx]dd%Y U*+Oџ*^󔿓UCJFQ+IuЭ?myWlU+`/#_ۦ:yGܺ\Ȱ'Bqy[=si{AJAu_eqNK e5Q8r/t??#V#_O1yQtMĒ-=)er@@c cOί[YiSyȗ^ZI&.qhˎxIOM;󕟝M1%ΏD%rS8 :6c`~_bwV[טp%{hI RQ(8C.Hϋ/(:OмiϧMk{fY uhYL\N Yo͋Ņ嶻/ȍl^^ZM:l9`.a&'+Q;d<5ZTU"sBJxrĀ:&yg?<5/csM5AN"?zrrs P8r/9Maa [}FC_ r oQue??z|~^I>M2ʗN p[Q¬8 5w $VzR@@G墶Mk61i2u弊:؇WOq}Yk9囅-̾UB5"% f<SշtKn5kXjXEB;!ix7L[$~Xy{A<%ag$sXʳJֲj$QĞ<֛3r5.^(@@a?)Q̝"]ng༚W/$%c'읻J$z]NHJ'[kgӭA%֏'g#nZ|(r/|9#ge/*K=Rԙjzf$G>*ˊ\9D7}8g/64}~g%~5}7 hk@@qBE9w$?6%olQKy> v#sx&D?﵏6||1jʇ N Tn䋈<# wZֵ&ݭ`5Pԃf2oM?LԵ;vgKV2#|Ja@@[*UثW (G[ɟ˓ufmkaؠ}NڑZ,LQFU9K;@@,~X7:Ԥ[\6ԠO_ qux}C6.ثWb];w~~jK#~\Wf}wE5dCrjّ> f<8e]Ɨ/7./!/吼7-[i~@@Ť}]N-ʥQz.KUثWb]v*Uث?$IZy;qRik j9+PK9_zEy! )oZxV|B}/ xG3?8=;v*UثU,._Ӷ縓cK188=9qqNt>l181y%*ߢ4--\s^I,c@@xߗ7Nwc8գyʿjw$Ucq,B)75a /_/鵧q]8Y.uegZoW浬Y<èHfׯu{ZSÕ3m@@C9qH$ثWb]v*UثWb]v*UثWb]v*UثWb_^cPO<,G7ӚLjVtRWqB~R'?b&-+GʞWDKL&*xd6o|swb]v*UثWb]v*UثWb]v*UثWb]v*V7P[:W )/zŠDEt}zWo M*$"! X$AuoNDxa^L{qoyMO7qidĭƘ̶vcI|y= sՒ؝ОzmeŸyVef@@Z~1QlYJ[E,mD⌤um#+hdu$F:8X[1< "]Cِv#+kpl^a˫+V4I[7TODt?ִ}˱[ ;JR~7L@@%tR rEou=K Wsż?X=As qivƞ?K_di<'+|_Qo;ּsn×cɿίF^Tfj6p|KhoMo;8^ǚsa'̒u\RKb EQ6 Ќ(F gv}VAHoce @@㕎Nds|M&Mׯ[B4gt2zw2c!!aœ M-]Li~\yU~04}[OB=XjOfg!LVWE~[i?SۘRm^8W⻰QQmB:Fj1ǎ/)m{n%ZuژPcp>?'hi[V)%h^osQf|z^KO[,=Oc#?B2Y8n6l^/lHXdhfHfCFGSUe="~kC9O8oZFHfRxDjN_}G߸*FH#3[Wп}?^_EyU)=uJ\.N =r|zy+z<NvSmsmulB8Ҁf.,Qss(`%QJ#$zY$HnߥLN%esy+ ɧ\ͦƙMnad׼KLue󌟟PK~Zk[e_RX4wc<ŗx?8SfN}W*;'դ-A7(\{OKf-J4{Z1?F\qh[ӺV?/\&@@&D$ I U$3)!/|,0cyϑ54mr58.lCuX@@.-dS762 w% {.NZb7k3%~V~fi7kr e^ҙ6c5j&%KK |/ȟ_"tZqiyŗYZX$m:Q~-K,eG @@[r'rϿ_z}gm&|}(d縬"RHܨaU9N1wr5cܩ1q24k,yҵ}M z|;W+_8<$m!G_~i3_yHgpcpV)[v9tdo޷8g$y C>aӦ.bx.mh'""(3u v<1?xǝt ŧ]%-,5͜L8ÐYEL3FNM<>ε8uA ߡEnaTpt!%$< s FI\D1y#rZ_3VV^m_7:T47)-ۿ XW &XWH3 lu 87XVOA剮Rhޖ !?CQ[It`gE]hujlVNٔ; ~UAcR ڵf-_A&ϟ6Zc,w?+EevEG= wڍd_^sxG|7,8궞h~῵VTe'GѮjd$aG0q˟4Kȓ~^jʾ,?U?]/O1/m`6!9^|rm_ꪊEl+xWb]M:{U쟑_ߚ>KSO۶~][yI-ŬM7I۔[C? zq1h8_ƣoy1:d2Asq7 dpTmj%b.M8O7lhA zs=ջv*UثWbOO?/.,kS\XG25^}bE*j~|G_e]Ɨ/7/_$MbM%m+!Ų5y69C]|9U7y9y{??0qoʝyHY,<ˣ?tQ$`asT7/9k8gk-it;/~bytV)V5{VҍFάc$V*jtwFԥu-WE?wnξNٴ>8ۤϏÙ|ثWb]{GaXLl5T} GvNxqGe~WR^w~J_䛵6x ~bIp'+5_ֿߚvMI)'45 n=|UWb]v*UO51Tߙ^pw.2][XSzDUU6y hj^t$^_{Vپ&28&^ثoտ0|_=~k{c_[GijO|biL;5;v*UثVEy}u/[UvuoQ>"H{;󙟙bGm?.dPZ)wԔ(»׻gV3C|v'FBws sId>,}9~X7yO+/.Nl!? YrP d5|QEUagB*UثWb['Xv+H-44XMv[Zg!,2 3 3)Ê5>6ɕL!ev]饟o.%3Q,#>˿Y-??0d-ᴫc׸k#'2 rO8_մT\4;2#OX>ށoF]rPWӮx?C[w[r@@QVu6}cܿ=WNk#kBo܏˼(O5`'O'4WDkܿxBN_ZY mzkc~F}KKy{JuGsZz>50AOɈϐm.GZܞUj8ձ۽.XSC$%/lu5V|AƓ]a^#iF&?_0U{5Ż|K?$-PVlrVH'RЮ ֧2V.#ċH4/4 4:KF,:k:~LY$}k˷52?îX%mR1laOMϞ+_~iOH=qΑΦ߯W(u B|m-ͬ$_~AZHQj)^hM (jpNY{,21GRM |A_G9O8*#Fմ耞1@@M.bWֽ3~'?TGfFFg:y7Sm坌fFoXܕ~irs 8r/?(?4G/?VL5۸-6oOZ_?V 4Zmlɦ`uD U8smKQOXKnhLFWpc(ņYth9wO&'`>j~[OF#Rc l\IrCq}9u ^gcm6ԈuPPB+AJJ`2jgW%VY{ }ƜC;<#yp{Q&?+|a-#5d~wn)T~:z#&4u?^ISi(-atT}C qɄ?"0uO;y@@n)M(zWn4=+9N",95fDFA~s6y s֣y{,˪"\$k %,(sCMǚPfG$/1?7?.W:4mgAqߔY!H̨g,i܈xl>_zmk24] GJ1e'U8ybyȿ>r5w)@@8!#. x|a?~8,|c"H}?Na ̊w Anx1ԏGMḼɬ%F&CN_- qr>l?/2үe ¬)[֯5=(i1e8bٟv;Oo/=Ï4In6e>%zV^ OW3!3`>a c]Eo<7~W[/.s^ 8 zco_ϙ2#.-O4h=$?h)rt]v*UثWÑjߟ[wqIo/(Өzy7Iu\Usj%~Mi3kgNQ4e?UndiJMf^eRUثWbTxf`#@@YUw8Gq"jd6iKKewlw(U;ǚ㕻8WV&?$#9)?,?'qIy~$ ?0یZ1w1>yt(RxoS/sSǫiV<}K6[zF2m͛v*UثWb^ 8msV}~ɟ>JՎgLvV&a4:)[@@\%/Xa1ta\R?Pt%# vQ]3:oQS{[k }vus!jو{u?BY2oymk.뚙튡 gOwom93_ qȱU9H+wcxrĵ148U9 sNT[gWg1Vw   $o4~So3Ϳ__?)4<:C}\ӏ1U?R7U4Rh'J#Ԙb[s6ɬ8BhEׅ(ewWqȯiY$k ILUWG ~gοY>cZ+ %GSxoϕ"iw0n5˨f{o,y%+3BIa<+FLy[⺴]#5Hbs$LOs0N<|g~[Ch%յh:u}̈O[Kkl;{SK]lzwm<`x'+Y^HqlÓÕ{'5cGV;"U%u,cѲ+\V+D+fSItRCʖzyH8:\E9W3 _.u KI/tJK-GMK[9E)bAKm{ʱ֣=9*ѸXPNabLĻ&9ߛ>J-5ȼE@@muj_Aδ~˧1{Oqr6t?[m5F[9[WE(ɏ''śil^G3WyVӵ2ܵixdn!:,A Y2qz1.~Z]j?n+Qgiw9(lKxOl(SI(6wӻMIh |9fBKVHH$ >c.lu8 z7h^y|4y$K؈WCRFd'<$6cF2Ϙ9 mCAM} [23Q\: F 0Uqlsc͚JWZMo*At%}'gٞ=l䖝wWkvVqC50r:^R6V2Oqb.&?rB㇕$θznRcQq`Hh޹\ͣ_yKswrޓ]5C/-F5Trt*'OD7%FQQ>vfWW^v`/fRK})(/f0Oe`/ Us/ 6NUثWb[v;}H4/<~y_iuRqY%#,u~faMҙ>){Η7wdWspݪjSԡDZ7'|L0tȿo ~ri 0#cUmZĒ@@n1T~ S&-Mqoc=ǘa9K{;W*ׂ^ 8l嘧+iϋā_14L$! *uGHv*UثWbҟAuߓNjLgmO_U p?@@ɘ|2k#%4a $sk=9*f424BAZ/2x sb]y2&Xm1?)`sV{(G.vw/tO凑4/=T\=8[HF^')N*UثWb]?r7oΟ2tQk- Ai5nŶfn$@@B{b7qqq|HoHf׵WڭĎo?R苊%<K^g /Z9UY&LP:<c~+Fy}9~3EߗK5Q%JxUe#{}يv*UثWb]v*UثWb]v*UثWb]v*UثWb]v*Z;xUJkxo>M=!;Tv=Vƒ8&1H~P$ڔ_V#P>*{͎j^_۔q/ۧL6ƙ.) QgqlÈaɔ wu&p}2֊ASKeOd񻤑::0[U#=kQ9<+{F,Wд>ٍOJmuhOL&@@f"{Z5q%u*z2mĄiP_YJv$e?;Otӵ}+J (RWr źz{Q&x"b}SʷF+ŌOROoo~屐.[pAFlԡj%CIѕEZ#OeZ|-W%eo,sA#<A22:JGB_S4-;Ƃ&cdPWU|CO"y_pTR(A 9݊G |ۦ>u1Oyڽ?}a|BacDH;Ģ`_ɺPs=s@@A2״o2.!nHHP_󍿛a/71bt[Fvk8 QLڵsc=\>S {?H96 CDw|%F;D $79 #PǮfO<_˖oK46"3A YJ0NKQRG%b~dz~SXyZ%!Y.P2BIcC⋙<&-Oÿ%yD}Xi~ /іPcL:?3?)ݥEi5+ nݝIU+'^c21OIMhSW%{iO[Dȱ8_RK/01bvUcõ?/ȫ)]rh=9VR. }-Z1FL&mh:><ǠIy"̚r͌ fU WPp`>a )V\Z^\;/ -ۑHǰ*h3,xSFx]mo/8jSD';]I)@@We`OL\ KO/uO/{UsyaF7Gw!rz˞ˤ77oW[s1JX qdz P岈 &U~Z~jiko-XivgR3>3I 8I` ĹC Oǘ:}GZ\HZO-̋ so]޼ki E{kqCcNnW0M=~j ZQs, Bk]똄v){w9 6AgI*>3r; a7MN<-hv*UثWbO55yS3Kk~b~RU*5u]KVzS|r4ظ?Z7O"hɫZ%(sbRLqv*Uث#wu ˾v~-[y."*s{ey!mÓÐ/Ο˯/U>^63yN巚ϥ6o4#㍢*ĺYտ9;?(sVHVd[оee`&#)}v*?-v?S7? G4"*86>V-ʿoJN%{]Hг؞d̍ iM6v(@@@@@@QWb]v*UثWb]#ӿAp'yٌ/O,:ˊhm ֬o`>>& QnzuwvR~^H8 +ZauJBp}^By6%y<};HWZ{Ex~2q-r0*C!*j6 &OYǞ Rx.юaTO^ rPńyBy5DrZV{`z+%|FvF-[UӮJD/euDH3 ۼihk/gQ>o&N"LnɌdQ|uwo,\BOsC"tu4*wɷOڥܵ$Oã+ /bl>,O"qfbοlzfUnx8'rj-}wjvX2n%duuH71Ȟ Xn#pAݟg>~][OVUho'ƭLŜN9Xcs|5"k>Dx7+{Es=U AfLf$,8S%;aO3i(|qbQsFI0>ۄAܗcg/K ʯ8MgmmdזozG_Cb<3im:L??zc!]KŤE.7ڰ'KVhqEO~E^N$Ey^Y5Zt4{l²/1#( xxe9nj%et?.9霚AYz\B}r3xa C$yɾSZsQgj~&9ypk!0\AGQ1WWB$Zky+-w wiYw乃宎_}G~`iڅw\i0Wd#Y#*-փ[~TDtS-ڊE+!Ilzh[9X=xWͿh4u(N$vsξSlK|j⠑(s8/G}[%^A.*Z[MInޜG.eCSg&QwaDFIwi?wReRdhr䜜{&3G_?_F佾4/y1ui(A ` UA"gaavub{op k>c a.gyѦv~-@@/#\#w>ZJ<,zN֒x͵Gt ƎLr};9iwW?Ayc})'hۗve|ɧ1~Pz揘ut͌vLqL-qhVXiPqE)xsaDXz6"-WȼCUˎA1ixx[+BwSC=^k b}؜cuYpK>Lr'y>mT_#3Eks<^y'9#?"p ?W? Xh #Xs?u?koO̯s5W1qH;[RENO'xOb󇿗zn.?&o եj^{6_'f`vd(͘ڙܫc1857HyVE ٰiJY<#~bf;v*UثW} {*VW˞`mAt" okX*qFh>)y;6/e}>ǹ%/m=o>뱉N0 79Sv*lg]_䱳zĴzG$*1܌Ux~Q]y#6 {IghV_]oNP>ђ}h׼F\9Jc"Ce.-.RtaTGFE+CWb]~ jtZm0Iy)jmĊ?BɘQk&*|l~M9 ^AE`4 5DW$*,$f3]|9m;~r~Nv^Q>DZEcqfN@@ڒM'0<9S8PM#BҼij| (*[u1:ڗsۄ)5ڐm]O{gj<3i|Qg2ycKWb]z?w/?.s/htmuyf 1=H59ZLE9a/7^=N?U]F Qs#MMolKWb]zwՉԿ(vλH~EWFf.7B=gs(?|"w]HجThv*UثWb]v*UثWb"4s;x.mn l1WĭZ_o&_(2|;?aN~^m#Wb]zN#=QrAr4'{\֮ysk]UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*0P[W )`x;|2Y@@ Μ rhIs ֆTè#%mt̴o3uEͤӀ~%$w3^C1_h`ڰրug_Ͻs%"M9cU3*])JAҩ1;qaI!(3~l~S 43/&X@@F~ c>gxlЫ)!GPGQL|); VjJ62;^ih65ysc.{EfQ{~ز1-湬K)RF 9}| [ڧq5=-eپFQ 3=K#ߒu[l(fJSqM%hbUЫ)zCBo4k>E!w/lJգqQS |/~x^7Mp1(*w> ?aSFGɜQc2{Ky-.흢J::U̠\")n[լuu=6Q-xúف1 EA16kV\KeKV"=#183hF{vei 4r!o`ۯ")/,E<O*y++ T(}^i󓿔~WY *]OVXnŽ*?NtH \\<ɵ$?4oq/ ?;i*M5/evcjcq3E:w?/͟_3h^u(ryY qnw j%$E_r@@w˚xr9=K_Y˚-5& jt$$_9xlyv{5c.?2?o˿7Guoh׬kk~}Fݞ=0Ģvx'(׼\5i֗ri7\0d 9Xя,y2O$)?%74輳+mi_;ܪ S,ǐTm'yZ>KrNi6s( *DY)P߫ 9(a^Yu"U"فO~I,27^jw`g VIc ECs~xӇ;mkovw:p}{Ln冕0KO(bMSq;z$|mi~Y$p̒A2XWc!N2@@sWjNU?)a#o%pAl:h $bbAb_Ol.Ѻ YbO_=A=5oO|8g6Zi]VxSw;Bf>+:p# H&zXL\ $9iiΓZ ZD58ʜHR84Jecscw5ƘiBhPAMjr.PJ0T16r\'w&8y_VaSm淠n[v7c 9t'y -jWp"U}ORsiG'"XXUثWbS'Pߔ)tǖ[ցdծC-g2e2qq?b!4ȝW^Ņ)l^kwl}>Uĕo ;gߒ qi̯11&MU;enO*⯠qWb,W*8pdK^RY-$y%_u^I8~dU@@#Ԯ_/ix%D +EU҇5dSa󇟚e嶡̚KOHXn/4SBۄFb`K/<6NثWb]H8c}is:G,WJ'Qz1ksϊNMe;SaAʿԺWN|C~)딹Wb>_s;p<2.Dy~84_tmkQ?u63=;v*UثW,_󕟓ct6Ii]W h~}9DgW4`7ݸWb]v*UثWb]|9ZM8vG->X Sqj^pkobǽ?r?)SGF*UثWb~n~R4?1rAoxm|'xu'<ͦf>]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]T7Q[ )Lz>%Tfz1cZcO%a Z^i@@=X+MSH+[V{||E ^1j:-ŋ?Wuo Zi~=#JI]x߫-"D':>վ_bwBHyfi mw F8e=Lk1F]rٻrZ>%O>HDYy1ņ\B[GQřĵm J{=B٠:ч)G[&K-r7sA܏jt#2+3V2lt)EE.Af1qbF;=7ڶ}^ͧVkufSЃ،qH25%޴k )>w0kQL&b=wW̞]t1*VGWH+6WFV$anAc]WContF/m[(A|=ASyC͚ߑuShIK>Z7 hta,7-J"CtF&4y?^_7`?5[x DZ^#SLd`hoQc;2{I絺Kkgh-Re;3$ j<Ǯ2/wi%L70S)pF0J"B(H}- hVɑ}[FyeHhjl%A7qJAf'"xQ9x)bh&WFSFVS 6S 75˟1[Ae3"ounJx#DPOAmx@@h!i2ŸCߦxO'+.1B7DHQe 9}~]iߛFS% g@@hO1 f2ǎ<ߛZ:45#yGojەxH(U U$RU $(16sHyoI燔-=]OE D<.ai5OLL$b\DFX B˙4濩yO:/ :{ }UH8bFF$io)/](LUѪz^3d`]pZygZ|šH~aBn ;R< 21 /iߘ_I6DjaYyӼSܛ0F%j'0Z/"~k`Yܥϓyۣ'3ӪmPx\d2/zovo7yxgH#[xuG3&Ϊڹ n&H `k[uɟ;2y -q9m+q xe=zk:U) 7c.]ql?B36|yϘ%܋oVqkvR9nbC s~\B|{8udm&="^7o)FyԃA.==|7?ΗuqTRL.^% c J?;4}yn.?+lY!8JD%VOwSQM,P2;s6X!`o??$61ItOJo,cb?J\[ض˗ .^hd$QAt mg+H%ZP;C OsgߖvX_>[6zXXD{i$Sp G`s3;aW_6kߛ:$pl:kNSN25ƛu00ūZ%2P5 KK _kS7j~L#r>`[qcOts$J9{(O}1?̙5hʿ>[/$.{KEg ͓rU'rc GP)7&bn緒CBwu_4Kգ[ѳY :!&IKcŊ=^9.XPw*^ao"j:Ў=uxc9ثWb]}~ ~N,F< &&V;F5cu!p)f4ظ ;_<9W#]Yî S˩=2*UثWcG&O_˝;rB9|';6էv@@L?;'&^_PIiMOsX#\?ߑ6Y|ؼHd'$E e ٺNJPUثWb_}n>^~Nk3ULMcZ}f+%Z΃eG;-['r._B;O/l.=@@ZjsV֥i%FFi_`O>yKKկZYQwvp#Lk#p??_lk:ƥ];O}3٧ݷ(^Ŋ|78%gmV%?Rt65@@Gm̍/pGTUثWb^89YVkOh^l{:15|xpeHv?wf}͊v*UثWb]v*UثWɿ󖧎8/k_㊤B>b?_(8rxkK=O6UثWbYxfx4P*7?'?3|fk|VWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWbZ D 8U4)*SQ:j=I+[. E*،,S8CkƬ>x)7ޒ^[d[*_K .k*3F~]Òb˭M?[i(efVrg`X?ŧ+14Q2BL% b^i)wc3[Νta:|Km-vk6O $9 1b[yw=#QH?dV(tGCK2s]{"؂G'q8X1 -n @@c4cҽT>9^nc~o7-=uF$^(>w% Y5)&9H;b@@(16i^ţ /bh~Ĕx0>M GBMm!ó!{J$()UfH*XDda(F&߼/oh)K>`D"=d=ZTd`h ucsqe{m%ݫm^.A2pȦ]sSZݸ{ZUvDD{9H3ǐ[I֡<^^A/iҔ ԡՎf&~\Bc/"4*E#9SԿ'3.,ɒ+̩Y-I!~ Hq698 (lmOޛF.kkFBЅ?l[5/d̗8ߖcmX*-1l~]N'ro4y47K$O)yOP: eDhb569Zu/\#y-宽py6}&p/$T;qw*SX&J<'xwߕ^yӭ"sgp -ۖh+1dm9xrx,v\ p6:o5Эg5YA[A_-;3xf&4D|Q{~Wy_e)#Ӧ4+y~evo ;fN9,9̛[q7^3(<+7x-[nȣ =jag2K!87 Gʾ`'X^@@^+{0țAab>qGnRo^9ѐgL{z.z _A/4=Vކ+ ЂG3H6g~\nyCiߘL^smV%Үͷg3C6_T~QYCjwz^-ϥ]nMewd^#8e* ? wpe[snO|872>kjƯ$w }jJu |s*9=-6LfmfO84U.u@@z6)E:)lÜ[1bb~mUh_ߗ]\Fz:זuHg"5x2H*~!'3.!#wϛ?%?<!C==/R/9jI 8{͎Xdg&#h}g9Zk˱jv׍ fMՓNFe3u[{L>?mg:丟Libm7 0RG(Zx^0xoyOqi~ͨy^rmǦH鷊SzZPl }Iv_/,Ogxv\Jպ`|I$eKX%+$nF? U[mu*Y}__[8<[[$q "! |zk|898O ? 7?V.t+?SZyKMKWc>}#6Y9BZ튽Q8y#VK]E(<ˑ%obտ71WJ??jIy埛\sUƕy΄,ѓID=A튽p_qm5jo$h&ˤoz7*e3̏ͯwtp|-|\tNu8)Da'f~%uZ\2%v*UثWb/TԴ-WJt[eWjEu۸xREwRG|$($7ƣ0r~-j(iJ?>HO"LJ&&!~fͿT9V7PrKEwh N?i'xWb,o!,1%5yy r)?3'n$8<ѤoU@@+9ݘ/ySIe}'eF IA븑]i왑 b⍎alKWb]ZJHRªŒx*|9>׼pSBL n^kԀznOڒ93Ww@@9]g@@YK8Wίpߤt3Z([sUث?Ϗ?k_!~Y[S.i sE7FcElUk~g)\=.ů~e4w&6ã@@ɱCG˰C^Ae~MmPv6NثWb]M?G߿?Wט={jj?Et#zt"k!s4b Λ<4tau8ɧZ'cQtPsi?&n\8Wb?X2ف"{̘]*+*\c3#K=o~kf;v*UثW&QSXs>渢4|6\~>z?׈O\vO1Wb]v*UثWb]v*/rѐY;Ȁr VWqTs5yߞeG<Pf%~LWF*UثWbr_:hge9ߦ?A?zG'^z"֕'f٭wOGAv*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثUi;brE’.TsJ|K}PkJ3{a^J~ ڥrZh#d2O$ ZnuaW6a_؞BK O֣{V>OрI<}}\BJ~]Շ_& Q4}jEÙvC߮b]f"ˎ6bӐ$=Xd6wkulVI#u#,k]/?tм}bJ"ܸ.vpYY!!EjtC5ݐ:Ŋ:oN3!鷺}5]nף)m`{^W[NLi` [OQ,~ڞOT`c >k6[kiXMB-▞߉.qh*Xf⒋`F?e@@Ic#|+r-yzdE*J vWFXɺQou/&uꖭi}hgiQPAFqe ggzrN޼#?h{g&x'~i~Yip__˥K|m^oTKM{ "IޜXBulˌHqE\֫%=OF?-3y'N.<3Ei,ÚI?dN r܌9x}'%֋\2AiAO'Heƻ#|͇߬q{z}-/b&ɟ=qx- &IZ>89Iml1vY~py?j ڀXMճX+f&r.v4{c.[OXoʯ/FMFm?̊5G_I9^XqƛpdG?]ѿ6teIto5G 4dMD-*;YV{p#[G2>|_SҰ嘂X_, fEg]~lvڎ{5!JϺ帧Z3$_Wp_.^Q̌QU AeA،m0]c1n![l\?6Lg}kD9EKH-2l \kYXk V F#D/kyNpe?=1.|e8j~l򅦜|Y;Ο,t( E9PLvy1pǘ|?̟ ߟ+oyr}ylu$CY ":s}!Ic[ĸL~?ț?>Nȷ2ZZ,&m:^ .v<<^3&6;/^K?CoIBhY,l7tnZZUثWb[UGϞ$-?yH$N[ݙBB !^?03N\;M18ErqҿqJ>S˸4?s˝5˸9ӿWƇliydr+C6_sF||9w/?w#^>>pw \;?]|h86?,3.4?h~a~FmH'<_ͪkOH.]NDZ0z]NO%tZKHE"MSF$ȮE(0 B}'Nv*UثWb?2/0:]S [T~ h۹Uv:,~EqɿdMg&iSΫqoE7`)'tY!6 ** b_*^R's~NkxeԴm=V[Y_y9w85ϓ?5 gLṱ^[=ER{;e:*Q[}H6|)Y{bO37e:H)Β7M}v*CrK_7\vaI^?(*ccʹ̗q}6@@F8/ :b]v*D\5vHy9GG{s8}S EkX<}i(fv*UثWb]v*UثWb?)?PZ];MoWb+0yȧjQܑ@@OіbӨ5^Vm#Wb]z-B p)#K~>?-J[)_1X7krv*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*%ruo)-̩؎0)R;Q]/bmwC2l W?# ŏZeʱtڿi} +D7OI`^k(bWlS,wxTzVP©$n |+2Y+8}\I+Ўrn1!Eus+W|QWOf}8ڧ4KS5;WєaΟ]ny>,b1ݷT o dou,~^&5kVq$Cn/N4A?-u-Uu@@Lm'zrb?h{#8qXp'~h~UXyA.}fOK ^XC%l[2El+#2Z}A=iʵק}gw4{e>1=( 'K2x-[+ycP?1`:1m9q'۵ޛymXO%=G$gFYͤlBH 6t@@c(Z%`na/u s|RsfoSZZ5be?7R:ʌ DM.|~Zpia 7#Ԉ%= g!I3 X}E9o~`fo[$YXZn#Rpb|'Zbc/mAn>N yo oajTp)(/3ŎV' <"+S˚u?/~RS2Y|Qjcɭ:jZOX S\+Ф<7Hk&9$փ|] Fޟuuc{nSIoyk ,LQч#3.qе.7,x4;{iуȲ |,R~hZ;I7]E{ӵi%45∘~mfk}s8['Gi=2{}f&u<}^u:aQo(v#=vҁNdJjÐE=A˜w៚=SkZdw>T 9I$Bs,a051nG"qܒi0yovYG?UU}8N)(e1Gߘd҃V>a̶ q]BxsCRjɢ#x}{N~[y3ZZk;O&<q, 5; br!˔489[uGgԓҏZYy1sËQؾO?./玪V-nd@@%H-XK(%=De׋I(LKP{4 *yo@@NЬ6Y/n.d._͘bY5MO]5-sZ7εu5xvnnaSElF""%bUثWb]SqWTU>'uO]SqWTU>'uO]SqWTUUثWb]EXjiƏtl5"zulX^eG|$(H# ?#%yklW\.t7y~Cyo7U(.0o47󋿘y8{k^PS'E?WkŐ<'ثWbb?-7p~]99?N[Age_.vpE*ܜUCG|cqY#~v#!vkYv{~g|3'M:wz|P~gb]v*q7POkpํ+J^ ?󊟚r~jRi[n{.ɻ\Mo.j.9I̺jCT" ?ίͯMHo+s+qџ. OJn+R ^K/~xe^>^g~t=y#;XbY˿ʫ3K6i>:I 2!7kzPT)#ǖb>_~7$HF#BF>C6v*UثWbInOAH?wͿӃs-\:Q`4Iw"M#0ٕbQ◹iq@@w?̷7C_obgDٚx3.KUثWb* ~dkEɧ{\]9nm;+o9DGOzo龷Y?-bv*Uث3՗ߞߐ:4Z 5;!I>}9/Dk'1? O1ayS~bEXtOf>>ᵹn-nICUxP{ F*v*UثWb]v*Uث?΍^=crp7.r޳lDPYiVr) |T:?'<g|4}.\×i8ڳXw6NثWb]gyQdR:soq7¹F.N~Ko$h<=7cC0ɷ_kUثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWby-իM('$ Lg8U{{hEV !mqfDsV{q HPiVCQXf?hOKt6gnU{[cM>Fdl-Zn}({dHL|={851 0~ᤵ7? Ӹo|&=ڵգ=Z5=Oei|l&- cYrm17X ѻm2 |h#]z|ҎA̪ y/_%qХqT+(ziўeT+\c>iyOo<<(6K$ceXulɌHqE򔖻=EA~2T[yM֏'ߟ/nb,;^F¬ݦJT0ݩ_7p6y 9e~\y^OΕuY4mIFOCB|AɌ_+yWVg_JXZ}n0 ,##a??t?#+yJB V[9)ОQ׶͔B^Hya<'}9T45~bhp"=`4Z4/|%=uE$2\*~.䯛% M ln=:o0`<(pLH;11޿>X5.jzy5}9F#ңh6-J&&|yO1>gb^- zw6+`?_9VIxǮi0zeq_1uQ;C*:<# s5dǽ}f.+.6h̏4;>bmFV,+R60}.q\]T8O!3T9,2=~~UҼ_*[I/lېj>UuyLh)-ij1N_>F-?4?%s3&X鳧 J hxY՝lUpngkj,ܭ6>sa o2qNfCUثWbU-z?.|#A_-I4m6#e +K};ZZheYo&Gw_뫟(i*ySJ7XT,@@*Srt0~M7Wϕ~߭~dy95/2jn;zU_@@]|%9  u(^\NSR*x[I/։pa.YͿJQiϬ8͓v*UثWbfk}uL4k6C}OCP.n3D' C/P}\5+u]XP63ek:=Ux"F sxɇ['[~]_bb~Z3:̃Pjzm-q[@@I*(HXgbƥk2 b;׿'?|`Ҹ})Ǧ ?19rv*c~ {q&5cȿ7#?/KVW4Oj3G )ZrQY'E/&?to;[?|&7#Nn.n&"[Qǐ6_^a~byYWZV',Q>y*\j]n|$IfaN]Ȉ|ݙnWb]{ BUFQXtنc~/F?y}9>-a] >{z,$>]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*Uԯ\UEV0b/)Miov /;kIWo!1~ tw'"~c MȬ?`?=Pb*gsTEMt'6[kC_ u#$$']zv\!3HՇ\A M%1,?v9#{"c\^ňyw:guK VX@@}>gl% I<]Or 7:{`>% 21gϕO=oC-5FR(L[2"F;rW^_g[ V u##h -yNu!iPQD6pv#ϭrnc1-<\yVV+R|QvI|;d;k3m|ū4l1$^죢v(1K< Lnc59W-.J$_ؔxrŶxŇZ}ŤC4RZZVH9#b9{C!yH{Pd)ew9UwRfǩDbl90?}OȚ w]:V"zl/qߨ.FLf wmC ۣ\`Cէ k;N~Lj# sKOU.m->Ȫ:M(ëRho^9ߗ-OP:tȦ j~VyJ嗟{lV OnO:1<&#sq0ܵ +J+"s.2|bh/<_ydq$S _X\Tw1"iH󚿖lhqУLG_R0R䯎U#[9-{fS6oyo67}C>KKkiA;@@TxppLH;-91Mޙ{ym嵾)4.cOɔi"| zSRz}ZrN_FC,xCf ?^S,y-cs>)TtkRe8Oӿ <8)J޴lZDԩx,${ߘO_8yOq:շO+/(G: rf]TիE_@@ߙ<85-΋[hLҭ%yn/7P[Z(5 ݎa&F1_]jwY |X kR26PXv*UثWb]v*UثWb]v*UثWb]\4RE5ZȓZJ xF`"$ wg<9!!-l`ԡ,~dhN?vӴ>eGD9OuÄӼŐN"Af<ok<]^I f/ix#"yc,UثWz4ߘߗ1܋;I1?-FV4F[{=)SU?~l羑m^f6N֊%%Y24w\Q>#̓v*UثWbS [\'8.+J  ߟ>Z&g*[4ūA_]Eyw[;)̺k'Tf6rc˾Yt#yM|hzQү!K(gSBSҀ0C)3)QFl$ߐȉ$qHP 7Jv*UثV$7'_>h9 poncelf?oc(xB6|j'/ 4!}K>KyP:؞v,t>D#rS9/qWb]|#? '9濑oa+x(bPƢT‡b]v*pNߟe^_ކRkj>9]Q7B=d>8% w?$7hv*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]`6=*Hd^Jz1TtrА{fA(乱ntlbE&jz_R @@[nl>>57| Vɹ&=~8Dw!t_2]\m]؍IczpkRcWI -rF2F0 &[Du,NimF{^חf,u8EOp$Sݡswo/3y;PNr-PQX췷ݖFV(*yEv[hּ>fCͣN;Jv=} 'yו˪BsP_iO2óՓAkK5,ocI*YkЯ V,ܨa#EQo-#Qu l!QZtuYX}\R/=#H$y$P>\=]q./]S(D&&8d/ˍG5n?506p7uka>&J?Zz>Ydn9׈x/p0N^|=k'.zĮ9?г͊Q|cs}Zp֚*guTu5t#lqAaly{r3<$irJ^ l9y9f-o@@4=JGխR0?BlF DE</凚'5Q4FLmj2 Wgoo3:Yy_Yg@@5">jo\N!ӛyө~_yH^ MkZ-ų3B/OC%( k%a4̏&i?LQy-Ij9i~lى:?df>p '0v-Q^Zf,#) nVu Z8'e`_b֣kUM[;{z5*!f`6-&&,'L?1.4$5؍oij:yk:|3dJ%wGC ###S o/Zk7nRM v?N70w~ 3c+pOv~goS;{muDƯӹjxON˘Px~\hez~qǒ[Xۑ$Pl6aƘgq˿z~ fThϤ<+Mgt|snWb]v*UثWb]v*UثWb]v*UثWb_V~fMo(|w#/~dۘ#c=?˫Bm]v*Uǖ_l ĚEY[D-Szk*|~o*z?#YӨ9V[5o8bh ?"n"~/an1Wb]v*UHi4>򼰶ciIpRAgJ[QEXvت=̆Ia mj:-%"xqE)H5M^'Tյ>OPoMs]_udqTY%>b Wʱaܿ_ټǿ_;V>;?Z7ZO0V>;?T[uֵ3qܾ>OwqKv5ׯϔ >O4_%$ͦA9?h 2pqg~n˾^ 6 !̧P`>,]v*UثWb_wh&ha%s$Z'ߘZ;ؗy5ÿ"4D6y曈^ѣXDG`v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*FX2(a㊥SKs$`u #z{ DV@@~^# .QB^о6;nF kvEd 5)zZKavׅ)O' ?֑xVVmʿ[eb\v%jsmI;)2bVPJ\wP4Iug*ۭkn)O?.Bo!aْ=X٩eţk)+-#zc lc3OyCen#{Qԫ/X"dlYKsN ,5 c@@xȿє?H9aq/\kO-~mi|eY D!#';׼=27yʚj42g{<$ j'}.ǔLK?:{'ϑ4Lx4.tYUa]r2y厡˟Y hW R1uB|MY1JtH+KMYK"$V_oN^Ǔc;o/>  GX =8t)ˆ)_1jJ@@۽}+[E(A;%!E216FZGg-D"һӘo)"wRN(e5̌Z[IFCT9#=;e#9o):o|tQO/8vX*Ԯ́cy/Ou_)zCPӤ)%+D;\n̘ŸR?̨?.Z$lS- 9{?* soI^=Mqc懱Ը71m"i=y8Vl\ɋYyΚ_lզ}b}bRe( ))J9_ mPh~[uѵkk}bh* %m.j7Df_[X+v*j=;pb?a'_zsub.{ZTwFbGy+v+RZ*AfcWᗘ>~OdKjcZ{{+Ԋ"A`_>aos?,;?]+_Ňx_'KkZ@@ diwOtH| .iSΏIcü/-?y L|Xw24VO:?$鏋OG1aZ<?>,;?]+_Ňx_'KkZ@@ diO/7y[sujK5WP!YP W%r,eQ)d;v*UثUH;l-dI`n24L9QFFEH$+;~@@ݧ;UNAPsWy ')꺟ߞ|8_ɮO2~Bk׍Y_#ʶt(VXWb&$<8??w0Կ1 ;-D$6aw 85I'yo#h>eY杼KURK JT248e]&xÙu.]v*UثWb]v*p.]a&.kU4y_߯_ PHs]*/eso-G("o狥f4+Ux`-s Tp(2)*UثWbXGA SCmDZJ [j9錬+Pc܄5#|$7"%\Y3^!9H1=_ m,l]_ڌ69"b $Ѵ/9=탭(ܻ,{&,DT=SV|\䷛[?ʞcw>,5?Sԥ}CÒsୗǦ=}+:0. v#{z|7j0GWϸ&4/!k^pӚ?k:LFh+^&u?Yz}IQUL㕹D_~cG͋Nk&tu`ڄChTokrqKdn]v*U}W\v~Q9u%}Kd壷*nW~<Η<-OqEԯmcoI-5M.^๶)utu;`=r!C8 =#1W7HU0?z-?w w^o((]C8 =#1W7HU0?z-?w w^o((]C8 =#1W7HU0?z-?w w^o((U=nm8./%K{KH|,4EfbTUOMoe C,/]pMVʎғѡ d5GW3f]v*UثW󉿚:HԮD>UhtPAȍ>` ;&cjqؾ3G\'}{90i$.^7qPqi&剐G-!*[@@dN<`?z *Y)k{ e ;bv*;s>͟STϿW yu *>@@ _[󁒴f+a}?S:7g_)ȑ\!>w9ϓ?1ig4&yj*DK-+OiqT[[H'_2{KϷ>uK1l..՘lE+j%G\U*UثWb]0{,9OѣV^Pa d}OR# U'ky(hߚzj6 5m.8/3tk$[2{Wb]v*UثWb]v*UثWb]v*UثWb\! -*ڄi@@Tyu"o+\"B&D wqu[Azx 팳\JԳSjn S8)[_^T|Oyݡ/Wb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UMIU h>pl J$gկf>=Ju;}yUڪ,wqSV;0?v)#隖1c,TVacD# 擮B-8 #JD&o8c;x#_-FI}(o$"$B Jؤw˖d:22$xUB>S7p} _wqWM#V/sٚ՚зVAuGg F<;J1%D-}b҇ڭ,J:u=} rbL;מE f711׈x=钜8c|嵆g+Ȫנͪ v |kJk:زˎQxuu/\i7cִv vtҵSY8s0/aӼEUSHUM:QGCzχ[Q|4~C};:.mR&Ҫ{0/x8БSwgǖ2|V7 Ku}Ȩqˀ',AyO^<ţat֠89xr!Eiw3Zsep4sD#2#mxai6ou;_ :G"N'M~A9e81=4z-<+{d<|Ul`m`#F5ߓ_󃿑PU̗mC Ϟ`lu;K[ $de^B8gdثQ?,ҿw 'wWbDUnWJlU( ߖJ_MqWa ]+ɱWТ*7~Y+6*O_?%t&]B8gdثQ?,ҿw 'wWbDUnWJlU~f 6ym&/0kZlyκaaiWyZqm J)UXac_R&Ǖ.0:fiYz<:N ɯ;~^j{7>H< Zj\guSF0X'X^;v*UثUՔ UMt#iU8奧I͞ZD|m  R"*kUsg5a*wX22krR~c~e"1[VܼSs^M;۲Gp^Y[slUثW?^|,??.0 g}m#J.2ԫU?_ry3Gmxy_m|"^-"MpڔfN%=\-f.(c|yثWb]v*UثWb*׼կyj\߆Gt9fGk#Sd叔-?ӿ(?::Qlbf Qg1*UثWb]|9e~]V񲵌4D$V.V(]qW~|~Y_b+jsjCo4[Sx-__ow ,7%  2@@N$İ67iw9/.^.l.‡heA`Qԕu!Е &LfY&]v*UثWb]v*UثWb]v*UثWb]a=*pVϟi-IfGƴۄ&glfO )!?Vޟ_˯ÿ,zpLn:Eeu%@@Y5K#@@KRx}qpJ(UUtUثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UMG(|qU1EObZ[]iCԎHhUk q?hqjEH7)7J@@)tsjZ+SqgZ)AKv<Ѹ]yizmqdtc WmyOg?@@N/̱6JmE}4.LwO5*,5^k%x@@,1Lu,i>kmWA(o'Y >̋-OHiD OD PK-Idn j"vC$b$21ا46ڶb@@ZXԇ_Ry_͚La]1Ɵ&۷s{d&b< /V̞Px5N{mOzfFŔn*F)eњR.-O>WQYJˢR}R 2|_Xޛ֤wvt,bP¿)?1'mog ;o!nP{ !N~~[Eߧ4 x>Cs&QMMPArX`;ا>:cv(o|"p'QE#zGƍ{l {'|9/>NQXw}OZøa{{Z`KiS% @@:TtK>^8)}]@@tO?e-+iVdzRn|b"%5k~gj7:}ɛʞT4o+5UҮֆו~4C||1jʇ 2Wb]v* *:y?zp~b^,Ye:ihp <ڌ٭>){Ɨ7wBMrWs>zs/vڷ|}Q\*UثWb]v*UثWb_~hX]~CW\~xh,?VW3?+'f d UGs7Ci>fb9Kw{c<='Q[|F/*ȡMUC:7tWb]v*o/?TV{qcto64Dst ) Od2x|QeE_w<'9ifn6?<סZEm JZ@@Hwl;w_zwѨykZ] 0ܠp<] *Xw0]SNR?#S{=ʼn 2^ GRhJU\G9g8;]=S״7Q!P7sj~̱bk8u6}c>lZZחl5 }!I=E9>8ۣ͏Ù챩ثWb]v*Uت}+\&Cʨ$_u(4?-9,wDp+XVK?Ȍy'mÏĐ5~UUp{uMʍ$}{ ^ …潻tCMI+mԾ-7꺛$SO%H$W ?"'kyբow榣"QpV;^@@`MU*cv*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*Uتƍ[~b~%ه5PYFԷoFAЯOhob(dq&8&n?WsPIYkIٙ>vܷޕWV2CҕA%h=?Wղ7Oe-K`R RԴYh:K9=h>n11&iul(oG'87lK u%^ $$?v'c~㓱&4bg $}KW~޴~ǧ1,]g,o:or`>&YO3H,PFΣoLvfb&,2)ޕKQk3$Qo8y1>{[s4}w0lYd{#] Uj2Wt9!{8VǒEU/۔Я'sl8^ǚ2rdr-<֩uezn(AZ5z>2G,3p~gZ]yYh=΅~Y{0?,N\|ߕZ-C miy2cKvuHN<%3^jr4gj;ep14TK˯8~R)[5|4zJ9-tSR*0 p2ﱿ*"SY^e?(lSMީ>o4ln.-#sH1$d¯~Lqpo:*~Fi* <wd[~d7WbL~d7WbL~d7WbL~d7WbL~d7WbL~d7WbL̓ɿm[Oz`fCKӴ[龵sFVVLMDxvًI.!6~Nfǿȕ.4ȿ^am?/ʖ~[TYćb J._?_',4sbڦMKWcq1݇"HZ/lU8Wb]v*UثWb]y/?t45iAqR}>H5q|U󊿛w_sy8?1|qyΏ-N}0i',[ `8lUM%=EǛ]@@hcյ'Q5Zف܈k3qgIȰOX?#u~b?OX?#u!޿OX?#u!޿OX?#u!޿OX?#u!޿OX?#u!޿yoՑ#4u>L A?zS's{qsͺ&?+kYSFmΛwrJ vVCV *i\YNǖoϿ? @@o y]d7HEԥ3G%'g;S"hAT8%}Rck35mM&?4XOA+2Gzn\튼sK̺F&~nŚhz/4+ȯW2fp(8\Q'Ua{',P̯CN2i 1N2i 1N2i 1N2i 1N2i 1N2i 1N2i 1N2i 1N2i 1Nܟ_zo'|yLn=:}6t. kIznٳ>Q3';Ke韝s9;U8Jy'z[/͏)'Z4wNcOWb]v*UثWbWHGu$y@@?*uX"$}w˷nuI rbyLrW@@><2}5Uۄ?0rQX:|l[ s9dX?HHf]ń74a>'$>!Ubbb]v*UثWb]צ*qU7(#0AO;: G,E {;k\Hb|GPb t_?1ƇI۴V)GcjmhrQն:L8E㯼2y ~&MjG޿rrj|t?/*)--<ŬA??lXKg/1RCe"m $*ҏc,dž8sJ_Tr# JЧE̕kMcR8QI[ji8lQhAkB8z,}/˖S tn2NԖUȖSU$Ԓ%zʢn% Tʿ?'ybDNirCZR† \' sQ;3ϻ0D/W,<.k=*ogZ$VQ$!HeAq9Hۓ(xbpr[K;Z7?myg[ܠ=VO_c F^lk MmP}mE/W`K袿e\lUQ_e6*(Y2?wW_CM+V_̯!&]E/Wb@@՗+}sɱWE ?>dتWSi/4r#FMI&sך5pgյDe&`wiRLUثWb]v*UثWb]v*ᾸP 4 Y&dث袿e\lUQ_e6*(Y2?wW_CM+V_̯!&]E/Wb*?,?'5<ߖoOG0Kn0IqK}BPJ5R Q'17,c^h2+˝Pັ.mfI[3+%iF!zN*U?寙<iY[l[OZ-x@@4cLUiț +,~fiw7ZWP^#$vX$UMlUE/Wb@@՗+}sɱWE ?>dث袿e\lUQ_e6*(Y2?wW_CM+V_̯!&]E/Wb@@՗+}sɱTW~GY:ޗ_̭[Sm;J0}ftBCn9 ɶ^8y]#Yd:;O5 yYYb@@׊z⯬Wb]v*UثWbZ A_+ypcZu3y&V%ǟ?-5 |},y3\mt nD=wSCsg?&X~ėy_O#-"kėy_/] ??ǯ再'׏. ;8 #G2x+ø/iaȷeWpo#-"kėy_ ȑS]> ;s]历)]|4|77ڸɦՖ#ėy_ ,_q^y :f{Ǹ 4N҂M*۬.ܓ?ᇑ=VРzHd5_GᎆL ʻGk[j5b|zycGO_jZ?.,t5G Vɬ>GoF/1} o|ܚ[Lm_v t7QN]*,?8zKΞ?^N*/A~]5 tjkOH򟕼+DE,,x.*]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UOE5-:g]`ze{t "s闉|i8?[翕)4|*iuK-YԵOL&рyoJU◐SMN^VK^lbIPGVeVU?yKSʺV\R-^P/noR~K-Zv*-Z~*)8zmmGO hdR!+;'{^*Uثs{~9 8q/˟&kM4mg>`QbHHn#O> O}8?9F?,$0>D󆕪rtX!3<%6OU*ss2p^PԼi~dw=YZE^:$R ƴn^_7~G?3#"5˿'i7 Qy> XOSj]G3Itӂ)#$!86nHBy+@@򆅡R[OJ[wtR'j+_yq ߗ~d7/2]yZoV壎8-}ZhO"M I_[///UUR?u2UyHWTRG֧݊u G?:7:vzy$0HrKlNR( ~!9I򧗼?0Fu#}h?>z?Vʽ1W-G?uO-]EQSqWl?TU-998~DjO`ln^i)nc_LpfALU8m??W| C,:?h#OzW~]xOO4u]Q6ܨ a׈ T@@G&Z8k7UQ+!>cVte(E*z˿/ɭ>7<;U;+)$z3bկwcM_NRO, sc/&M>,\'ґhgSCWZ}MKN!EtP7F?e9E]e9E]O)<k:ZݕʩkH)|F*7徇qKo:᠞0O b$TA2y'͚ϑ?&<چs%if)"Z$(**d*֌U|/?>@@3QTr>d^~UOe9E]jX~tjt_|iUףVnZ{k8.fNnP1W'7)6W򗗡M^UDEPZITD _ߚ_{]Nohl?5s: 2Z+ r?Oʚ~Ty qW/νC>H4?,_k} rZZ¨~s*q"v2z~e!y˞F򏖼g R\[ƒ9`kG75|UE[}"_.QOϔZS>q~ɍbяי-?-<A7?\s;kH90EپUrOqߔzw/":,zr{/'ט]^ثqOݱ;5i]K=RٚKRxۇ-q=Wˏ7ZF׼ wCgesyZ7;-<8ЪMrE{俛_Vm6KREō"Su4Fi _(?" Sui3B. nI?Ien$%+*`gSo3k6Vi_K$oF;J#դ57_ߚZ?淗=WY>je],#ҍن*~ej<n*-Z [a'<9G~kyH|}aMCHkm$̖meom7s,J2]Z|i^t6zĭ5ڂ)αBU|)u?\`UvKb?'?3ϪX韞z],w~ltҖ$dm6._vDuk $FC@@ۃ*=QXo@@+y_OAyͱê8Ӵ`W SZ,ADz*]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWbssWRַG?0~[~_Gmn s7xثprM'K˰.ʽVIYE =K= aسh̺\cVpV&P,B*jIJL^p}1u{GtڬЃW?GMG<~d~a/fqWPLVle- #oSGɹRZbOOˏ&tq_a 3bC'*|=^fט< 2N64}^H88xث2ˏBqZwpsMI";9Y@@ #pqW8hgMwAּ5)qkuo-,MՁPqca 3b?[Kq˞Z,F𥽭CaUFAo7ƣ]o>jo`&PMnc#rȓ@@i\Uͩ'jY:_2+;Y[xu>Ww9 ~SOm BJ< p?T-ըٝpE1aƄ+_/8~VCR%Ҵ-]EGL7ZFRGnJ~ Ͼ?ϻ*y\ʾ?<ꖲ42\i2|QypWCP_G|+ys_ɶ:f!f=H[f=Fb{U?F/t?^S=KX|-LZdZm6ۼW TerHטΟ9My7^^עҜb-gdJ})_1Wu42opqq͟c?g< cV7:hW38<+(~ii4Kk*ޟ<~,zbt& * N&_Aǿ~]~br_4_O%{Hք@@+h$MjWő늿U<5_o0i\.6|s|b᠜<wOLvc;Ku`b~T ȏ7cZܱMOA%z U1W[{`t[U[?W^P#ySGcQ5 7Ͱ[iiM&71UI4*fԿ [Y,/A -qpث9jy#:VUkk#Z%ը;}^%H*$-88ݬ~w~_[qos]2Q'팲'#~ 0ȧ"zbhw秙|_.H̳ZޝX[]J% !(Uхz_?%Cr^Wϖ48ynMduHm%xtˉ#get%C *Q??.??*AV$+x#Q(*c|?ؚUيOD_?1WsrmLtyϩcK{OsHث3'pyKp[Or{N]w2cKѥOU6nbՏw,s?ol>JL dQUK9_9_I_̟[{`t[Uu]/ sr!5ީu%{].fyFŮ.IY@@U}88 9!~e~byM淞{}r}<1B$ -}88ϡywN!K}_LLԭ^٬S%b{_>kV̺W` 4;)ʣ*#1bj6$H?z b[wn}]/%~cS?GHϔuu(o}hG/:r^FWJ_(LC~ݿ!'o?)_ʿ,^D$~XHkqvlTp#EP*ο8O9]K-7UlZy~K"*}Z=*]g?1?!(v,1ZF6H ੏֓|r؃*/"Nv[ZB繎I\Q??.??*̼)gͯ]SyGųOZ=H KHIZҠxb_f~mK*X<_ӿ=9?5jW//M"֖:|fKoI'CJ-8?qۊ\ 0T_ĚGMlrect2e2)"w{O?]G*}88ɯ4yOi&i6W ;DU=1#yMu?ǯ#[#iTe,B P6*KmD6Zo4b)}WYa(P?$D5N*;CO ygr3@@b<$K-={] vQ|o_ǍVu6Aun1)7=6=X3Rlt}:Vtin ُ2I#ʪ?_7aPa S%}AŦ[-*ۈOw.ǩ_嗐t?%\n-tO%hEI]%Fibw$w_͗r '_B7~% $LHFp/|988>_=?򰼉ougq`ԭ-ERXҵ_Я9m8ZayW'~ghڜ1C{%k% .mR1"Ӧ*oOŏOˏ&tɍ#Jg΅i6~`H,Xmm;DDPPLUqGq3qz~WyHwޚY*I&U݇O䷗tko}~}?W|'MqH!v2N*l&gr[O(n.-.ŦK%_Hai*I"> U qqy_HEz- DHLHOvrIqWCpo:'ϗ#~q&*3AMlַ"B] Un^})'Ƶ+y-i,]5 ;I_/N_зV )k?_y˷u>Y.'-idxK;1fbjI*'? GO!O,jzt;hi-- yZHTpu`fƓ98><]\++Vwp70;~? ?a?.柑$VmcD{VD]傛 u[}c9n?:Gf˚ơ*^+Ů乑!}Be42AA_ϔ?)4$h5e*-GT·۬Ԥ)G7rU}Yv*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb;>G?f7ZIWTV&M$t_vo:WOw%Ot;yL>lTdLU_WOqrɾkߙ2?.V=I 摩KJƼ3G|t0q[co6y) ERN(S~89q9q_.k~K,O_ %zjS*O*+4lH*??,{.~WyGWHLWw ~U4oԭq,^aa998ytC'h' D~eס5STLAy#b[kS{5ipW҃TDr$$cc%g_@@͊Ÿk/?LUJ s.r [?|?뾘Ҝ*18:|77? ga=G\!d1dPXFb#n~ajƛOهz^Gs]l,qZF*VUQ?CmNZ"ӤŠ^>@@~c~|B[ a%͓F֐~=AhΔdmWV/} 96~]￩+?:|U~Z()?o)]yY<:-/E[M8Q=I=e&_7GO(^yLƙϗtȬ%PU[2 hLE[A~dFeS[ռ}Lh:7_[۸ؙ䟏R~ʲӿ8@@<ըU89#9kz䟓._-s;JRݛ`j|UMOϿWS_*MiG?NjZg.iE_G"RCQ*qW?qˢi?~]t}/,b$cx()Cz|)>bO 7~J/җrLVE;D%ҎHUjMt[fG_6^gܺ-67Զop4Si WVbaJ*/KPyf=B~n,SS Z?">\o5GX鑵ž-f?q/+U"OZh^M%???2|gmjyU5=~ E42&}1{9gNhVξae=KQaNܤx?\_ч'W>?0~?UGW_w?hpk>a&]=ON=VG984_OΏ$ wLqqY!ryn5Ez\)~yrϺa~OkmmoceZwY'nj$%Wi:vhNic kQ{*(|9m9 z,UϨ?.?/{~m>*K|?ؚUيOD_m4!vv ܬ8]$UkB~l'''ky{^t5keҴK;Id}G_G?+o(XZmfl=: b^_/~AzѼqM߷S"Crhn??!-IA4d26rU UϪ*?E_^*UثW ſͽ~(}E' Q_嬶\k*}No-OiPzMgJ1Vm<֒j-`<WT}&.#3H5+ZRvUMy7^rnj^x˓*&oR9#<eኾjԥq{,_*fyGϖVXf\jVKy`͵έU :u_ևF887'B:w]h`GD`/ͤhPr+}+9572~k~]\<Xv%-hU *y{Xbյ  x{DQUU1V)/|t5]LkȅVh.\D  튾k?7.~D~s˞{YyW:jZv-4)%N#1R *Xz:{^'D_OU^WW8=9-WZϑ³EVi(Ky2%%䃥qW6k?'A󔿑_Z?9s)y;Q [ӵ7YIz6 H+AN%WQኾȚ UZh zU6jaϗ]늰oMK!p~e~ksڬQFYֳku"#u*w_/γm{󓟙7j~]Iy˖w1^]jC%ߤY-ⷞ>F6>:qdU*O"?D-:iz>aMtGJSـ81t0!t/0zL֗+fk_?K_Oř|Q^uд[wѭƥrd*<~B?zk_z͟ɻ tqT]ᷥv>Cc>"?"'065k{kG4;;`j71*Cu%yru󭆃w,rue P*#ur+6*~y#F6yC燕uo&O#Y,ŽcI QZ ^_X/t?k1k`s=.-B;oP. bX֌\B*//~E~ti~aߝuVKi@@BPC9IPqW=Y^#è_yoPB~whJr!v !;!W%v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb]v*UثWb_7r/O΍W7&sSyPTy7ՠJ?s7?w__I`ܷ6%fd9LE>xп_|<p늿448g9?o%Ҩ䇛^ i8ʨڹ^b7_?ߚyɟq+Q6p@@;. n jQ89 ث訟z󓿜SíX{XMc\ѣdrP=Wߛ+?2lUp[9Zbw~ ?UGWQo_[:,U/qc&J-"7Ȳ>wpVeZ]i-Cޢe_;~r*ht_9Y`tA$1&6S G0E~AA0yBWΞKgůu%ͼ@@ZI-fFW*n&q3O歧]>SPѰ9 TФX@@2UyT*?4&kEi'75u$ jbF*.<|o{yyzU>qKKkԶp+" 1!T_/Wo,ZZ6u/JMw-*>$2pU['ZSA/v?-._įGT5B]\Vr+5g,$}Ymakg2\~^yf#XIGSbbUQUUB@@tb/J 7|kKoElqW!k+ޱb~^?5_ t/9.*S|})4O_n*7sqGw'^ZxSZ?C^\Acֵ&r|,zӮ*訟zGpN׺gBv^_EDzFn,ኧQ6]2^yBٿ3w7|D:΢gj>GEK{w%k/.C#I1WGZ3+5tU>~Ik?ǔ?=*yAdX_I%Jp1*߿/ʏɟ/J~zj_eſ?0~?UGWQo_[:,U/qc&J-"7Ȳ>w;Ziiuq"z~Ϲ?,qc}3VbI{yAKZjMPf4,1WKJeeaPAF*sXrIXPm~\+_I_*=y[?.&?1,Vq,Zխ䒟eYr;re^1Wϥ/))ɏ͟8Yyz;\Ckum%~_FV5*c|98_?|skiJ,^UX,6/41U_?W.-&i8ZiM.@@4:uV1"3А@@*迟6ߑ_EhLNGŝW4fVDpʒpU8=^q~`ySzƵ%Ð^ >kmv1ܼNqW/u_7/jƱi^w([R{{6V7dVU)`*? 4&i[|hZF,.$nCq0e;Tx7^{9O8X|q8 `4۟VvW lsv*D?_|cEB^P$l%mErRݴmXpG~e/)=<|? h>c"OOU;ba %1^An!W?ÿ}V[o=OԼhe^|RǼ(cniYGcFb,oߘR};hU |WNq5?,48lRKsW'^~[ʋWO:.?nLzVqM'ƞ8_v*_FKW3䋝NTtXGlmn.)ڭ'(V*|k_R'u?4_kMG$:"+--ZG=$l<[)kms_:KI%|B4.UWo<_?ͪh:uu6Z=jbcՑ0z~%_TO_o^3989I*E66+TrI^ZALLU?ɧQ~ϳ"_(Oo9n?0'mn.5(c_j>\Mw_ڥ2 KQUoA,Pt$u_?X$5y~ohxG#$;)H[*q}g9InD>yvS\Mkk3[dd7; ц*"_*:ɏi|jI%ϦY^8n]Zۉ>!E*AzbqF֌V3m9M/[=Rؘ/툩4tpW9_C9/_V_ڷ? t~z?MV_6|-=Κ-Qp% 7>I [Y%~q^y7zttUo` K >* U-cF[@@he~VJ>_#F[Ⱥ6u5yRHb,ތbGv2*b_WϘ?kyrKsYhdT xqJGqphd_8'W @@ӱW!8ѿk,*~#g/_&i4M|i +Df!S!^>^Lq7;TyW5 "w$Z|S#Vh2wƸkN籯5΁q/dZ^W>Silik$.6kMO\zSF~O~Z/o(y;Cߖۅ)ZUo?)A~nbhM`17<Ƶb1W↓>v5$y6ћj|-̣RyqlU_aorzo7?RVB37虭.8 ? nBOƟebiM6Y%]R_rk}CCO^/rß^,mPsrj{UV"X䣼L+ĝ]?F*q} 8;?>[ϩbbiƓ]{X4x4VPD#V{_?yuIJ~f*緁_6Ϻ1͙|!Rh˧z^յ׬%~L'y>h=Fht*@@*ŒR~?~bϔ'5^Q˗M-n 2qGvcoH,^_>)/#snIkaq{msw#4VW',VVkqC?5%úͭz,"i&\>sSR8U>"*eZ Ab*GGX?|`^nMʹQOB.Wjn`6_ߘ_^OjHZ%閜di-^$䵧"+U_j"~[_jSy3>]$7UuY#RjOUJ*G}O~~S?++.-cZO yoLk kqiZT@@]g@@EΕ{*ḡEq;s@@'J1W>=\j󐗚ou bYI?]APM+ZUiZNcieV}+8`G(誠1W}T+gi)V]nnzH~x-Ϭm??;|\o,ED| uxzܾ)\UWG VSqR7XnkSU ?a:YWM6;u\֣劾_?_'~s~nC˟\Xt4;7sG/m'3PҀ*#}O??,sѺO6ik b3@@8aUURUE~}T+gi)V]nnzH~{+ϭ:o/_څhh+b&rqW>*_-˚ϔ<ߢy>aZ/A #B U>R׵KOWSvyg[մ\m:=VlUo͏tXmdz'Z{,/㊿G_?s=_X(HY.ބ s}Ϫ^~gYyZZNäyop";X՚Y39ҹ$UߍqWփIj'5 k̲[f^Pc gA*3|98 [ OE`t4h/^HHfeKnLUn~~p=hv4 1S-syMY7'#rWo8 yH/Fr(q)r??WL{~U_qcO۶:e M ,U/gV7_W~pK~Z~}y*WG/MR{[RskaGu]^ry}-#k7E ~y{~b/͟5GETS+$v‘FVH*_ߗJ-.Ch^K])(0YB56y1I8/_?.bHKy_˿1yJK"RR&7SslP!v銳¿čkqmAo*QW,&Fzcܲ0GUJ_~jϜ,3312Ge|t崜ZN[C%1ǗZV~ZiѴMHiҬm^Ck.5jWiSr'}=ׯ~r򎥨~NXKS41]i737f5>*|y%eѥ6pok}?>`gl`jQ[eٙH*%*:@@vM+F32jaD Qe> ֱ!/73>ꡝ$859%9³-K^pz(n/]> {n+e?S>zw[}'M[s;RUuw ;Չ0ὒ\kւ>:\YAꝇ%>⿇ߨ Ěȃz^a6݁{Z; n[HɿY65_S)=5=IIEas׼fJkRrpɚԌ[;O>A)Ns!= 7ѝכikr*!YzvZ[|@@Al⣆|RtNݭݽo N&ܤ7i>57?:W&a7욹e§AyجYK y~W YZ ) w虒ARлAM|t |ֱPv7a'o$[\}Ddtp0YMUUy&##: e8B@@ Cҿe޼ ɤ;:xAJF4fM}y ^GgG#޻xJ.noxGw 8wDW>G6e"ωІ\299yƍׯ[nMMM]v^ܼygj䣯t$woݔP(jbԦ't]wgp|Ž+tZ 츻߷y4>Yo7NqX};'bz~RI...FQ: &:=z80'.***+++,,ҶWGͣp\p_K<&yW>\rM}_nnno>3;Ttck_y]ZZtq922DR[ϯP? BL>#///##Ce>}#ky>]yNޓ#MΓG;7}(O;xnqyy^ KDS;ϻ)1l?t-&DBow:Μ9311^dij/))/ؔ20EއP(DӸo7%cWzEV.ݶޏbU yWx3\oIYO\RKh+7nFc4|gՅxܲz{ siiJ_ŋZqc`袏ofWM=e qYvځE:3v*ŇcЊ _Zz KVTfZ[Cf(ܘzY<`v>L`:שfܒSW}" .>?8&j El YWT_$KHV5F$q>Y *JS/_iT/:?PJSwk*)32'+` F;'oZ}Sd '`I!STFчN|+KKvWUS̯M[b C\^<53c) c,- ŗHRE):79v\i2mN􍦑YVV7oSY( 0bKUEErxGgwYK5MWlqia㇞8-Oot,눜[i}>ɪ(+ٱ5N4bwL؊ӦD2`ѓqMShtjˑ{vog N^GڲF51ݰ mM*J7SŗyAUQ*)x7>5<j/35[|*b%vuf3hŚ3bq[-~#+hol#5,%pm" ٙP^KzyjV,nν OzD߻YNYX,ė~- %kl7 UQR6Oݜ>ݽtxs5O~Vmn~ۑsOYZ>z=͍: '(8Ljyc#~xUͧ˚M6⺮{@@1-|9'/ az3Ou逸@@Q-ȈA}Bݻo/Wզ&i/=ZXHV^॥?Oo=_שMHqS3F'o#,:K.}K_/OڭuZ ^n;ӛowf0訷~'U9 diZi'NW ũQp^TTM6"DE\wj&kqƽbj GH>N>?d?ݚխk}2ƹJ|B ]gfbQaUrlbt|||hhŋϟy7^{5gW0v߾}pTiS b{,}Q SD ާU$/8 h@@@@w{@@n -&s&DrvZ!LI S f~ccnh׮`S'4)в!Zs`jHorxS>?WYQ+WP$N5e;産X6uQ}: /Tf&DNu/-Y7-J5iBFq/-#OlY?GT`9USTڝAz9e<1wlCm^ :}w^%߂e3vݻE}5$//u.;O~~o˒AnSDkLIUZ* +ڄLBA_vlٌ]z~}(e_]cе)%mJ }%sp\_8#٦usBԅǝ]x^NF^N}[KcO]nǩ[7'G&dC`Զ|~xؖ5*I'fO}dGUi4mg*5}Qgv/,83<:1skn9_Z~E3 *m&FM ko.j83imj*/) , %g*Z9dsѡ1q|9Ȫmݧh>ߙ1,|Ӣyt o*/moi h(jH&{ZZ?>g{/^~cʈ j l52 #~^xioo]aNyTz :/e=XWwOGًcsK~=PIq"{[RɌ_VOh-m.M^NU'G"huU>UbŘM[ѳ6h~ZNDHZB4r襁Z]}[k]Muf]Ei'M=kimj6p'\4ҩT\虞_ ƝlM'J*CG྽yYYx_2B;wnkٶmdj3qkVvr2mс^3%鷺t]m:ZDyѓ[n-W$6CMj2b~Eܳe϶֎co?M;/oSO=ks,B^=z|zaY CU?*2\>5;uBcecVWl,f;\˧*;tvydd-O} k"ruz&cFngB|@@^겲'kB=:FEYRw640CmO:K|*ƯC(6gF}zD]ڛ띬\_#xh;vP:r Y f$HSoWl?dW}>[%__y:g4|t{H_0kpm>{ UniյsL7<,A^'>LW_}^z}YaUH}иWӟNO*0cc]2tif+rJ^݁=/7%AT-xʆzwifIvtHk2gfmV7yrhU7giIlzv'^),$ ь yhk**TIq=j ,z);CUwoՊ|V}cč ls3%rYIv+܂8)R劣TI$i0u&|W=߻[ ?#J[;ub_뮑Y9QγŠ9<+G/ܘyDmIhTdebǩSLRXPLy+L 48io{mo.]-G >Q./+qd,b7,~N/ަ 4UҡlɲdeX1YY.\XZXb1ѯz/"qؙb sL#~}vکΎVWmɡR%vcڶniܺKc}=+0IЉ4lMg,C?MTǨ+on9ɎmڴvkIqQQ᦬P($-kwF\|b5{{]\/.fʢ!jٟM볋7f/**,lmj\ /0sQ%4S_Ĺ3SKy -qKO7=-l ">{hSAMy9f6e>ާ͛y$dYƄwhuCk*ۚ*lO e?R_U]Q7 [Fs5SWNeݙf[EfPve/@@N7ۚ*lޔːBl]O:?|ajO&jt-1oMUp>E] $+6oΦqhǺ7_'r~q~~~?aFFw>>QkF<ߡ>oEEWz?wk6K.ȧ_̬;x`yyy[[$CNBi,t٪ n;'qG;)1c=9RHk\w]Zv׻/H^'V_L|$Q|zOU9m98s'E,ɾoJ T+jkk?O^zllɓ===ϟя~3̾}Z[[~?c.y )sW^lNN\1uK/؞,<Ǿ92@@>]ը _ pM$' &s8,n^ZSle9o gS>55577OM)ܦ&`y ӶRx!HԐ"40ڛ)T8ΝS}!_'=I$Fl_9DwtmZ^JЩ۽cܢKAD樞8%-Nx^ h`ҙѷ*2KZc#Ë".V<2kLkr,߻GRoGW/MMM9|ݓ&*cF܌*KHQ3.+7otw_`P쬚ҒO 1EP(F ;78.g" 4/\XRh&{2$kj4cqCd%Aۛ՟0@@55/wCCںʢB0U#)}Я~Eh e\ f2hf&c0Fb`d&2 &G1x;:r/@@ }?(m)}PJ8Yk;=3єqs{~kjplR/6YSS zYte^IH+TYƠbgԵHx#)>U1 , )r$k]$^φ@@kU3R0ׄ6U9Y+c۹ ӓ۷&Q=h!VLF0,% NCڵkǎ%6E~{ݴiӾ}^xÇ?쳎+"Ktxb/H%ؙ,..6Mb=z4;;4.|k6:: _edd޽_9!ukօC\-48Ͷ'-4#daRl:q Bf%֔Kvi~[XwaX0)/ߊ.Bc uNv(˲SRHf-cX}X !X ǸuKrn,.iyyy c~֭#GC=e 0d  ah' g8AL 8? ٶG4y`F"',Ј89Kp޲]`?ЦS aBQ̀̌@@C]Ss=9_ci{2692s΄uutIȺiį*h܈ a`Ćθ6/9%-% w\_JP{6ܜBx c)&Yd'"۴u-;֍5.4_EEIFIyyZ+Shش&o\ٜk KVxg'2L=Zz'gm] ̈́B>#UC" Elrexȱ-)+-XSBc<)$)!<. r'LXDPCgxBƋYcLX:3_SYV6i6a:YWHوViY򢈙r-*>`peheeu~?%򲽪BGnT$E@@8|ຊ^UEe~5~#tAe3 _dcqJr3$t~)kM-_30psvd|1-ݜهڏH0Q0:`Yɦ9<ɌĹE;Dɉ ӯ ȢLFզg(=0A⬦Owut KKe tE(5e⍩`0Aq`J*H8fHGAґl|~ݲ¥mu+H#n8ſDx?9;;xE2,CfBےx -1LD穕X(+ .J6nXO9#ޮC lMJX_dUn˪ ڕ:MDs4uEǧ>藍g߮Ftƙ*ƣѻqg>+JD4EJ:}J2&3՛a֕˗/mZ_YV&"O#M.eQ46T0$a^Pv#Z) Z:Z6i)o w#㩳j<33wkAw+,X!-ȺD}|!(n+SO=7|_y9w g.};Y\ O:?k+,* q{}W~ᬬ_7ñ'&&@@}Q-bri%$.`wţGܹ9sG [>W_} ݻwoݺu+;\< tJEm3 h(]E t;`s}'+'`u#j:k9;18V]'ʀ sߩ1K`}ެ|(Cþ&N@@` #EO8);ËlseL4=>lDkn\} ZAȦ'C:YJ