From - Fri Jan 31 17:49:18 2003
X-UIDL: 3df25b31000005da
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h0VGnH3T023772;
	Fri, 31 Jan 2003 17:49:17 +0100 (MET)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h0VGnH928525;
	Fri, 31 Jan 2003 17:49:17 +0100 (MET)
Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAANzaiR3; Fri, 31 Jan 03 17:49:15 +0100
Received: from aria (aria.stsci.edu [130.167.236.125])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ADJ06342;
	Fri, 31 Jan 2003 11:48:49 -0500 (EST)
Message-ID: <011801c2c948$7305bf60$7deca782@stsci.edu>
From: "Robert Hanisch" <hanisch@stsci.edu>
To: <interop@ivoa.net>, <registry@ivoa.net>, <dal@ivoa.net>
Cc: <ivoa@ivoa.net>
Subject: proposal to register FITS MIME types
Date: Fri, 31 Jan 2003 11:47:32 -0500
Organization: Space Telescope Science Institute
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Steve Allen (Lick Observatory) is taking the lead on a proposal to register
FITS MIME types.  He is looking for review and feedback from the
international VO community.  If you have an interest or views on this,
please have a look at Steve's proposal.

Thanks,
Bob

(Sorry for any multiple deliveries of this message!)

----- Original Message -----
From: "Steve Allen" <sla@ucolick.org>
To: "FITSMIME" <fitsmime@nrao.edu>
Sent: Wednesday, January 22, 2003 2:58 AM
Subject: [fitsmime] reaction to the draft?


> The Internet Draft to register MIME types for FITS has benefitted from
> several good suggestions during the past few weeks.  It is still at
> http://www.ucolick.org/~sla/fits/mime/
> along with the ancillary documentation about the process.  I hope to
> announce the draft to fitsbits/sci.astro.fits in a while as a general
> call for comments prior to beginning the formal proceedings to get
> clearance from the FITS community, prior to submitting the draft to
> the internet community.
>
> Reviews and comments about the draft from the VO community would be
> most welcome, for I remain concerned that the draft may not adequately
> address those needs.
>
> --
> Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
> sla@ucolick.org      Voice: +1 831 459 3046
http://www.ucolick.org/~sla
> PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
> _______________________________________________
> fitsmime mailing list
> fitsmime@listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/fitsmime
>

From - Wed Feb 19 13:37:41 2003
X-UIDL: 3df25b31000008fe
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h1JCVcTS006038;
	Wed, 19 Feb 2003 13:31:38 +0100 (MET)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h1JCXUd19552;
	Wed, 19 Feb 2003 13:33:31 +0100 (MET)
Message-ID: <3E5378CA.5040003@eso.org>
Date: Wed, 19 Feb 2003 13:30:02 +0100
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Niall Gaffney <gaffney@stsci.edu>
CC: Doug Tody <dtody@nrao.edu>,
   Michael Harris
 <mharris@head-cfa.cfa.harvard.edu>, VOTable@ivoa.net,
   dal@ivoa.net
Subject: Re: VOPlot - Tool for plotting VOTables released.
References: <Pine.LNX.4.44.0302181235340.14971-100000@oak>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Doug Tody wrote:
 > While at ESO a couple of weeks ago the topic of spectra came up in
 > connection with SIA - the ESO folks were interested in this as well.
 > Images and spectra are two sides of the same coin.  SIA could be extended
 > to prototype some sort of simplified uniform access to spectra, or we
 > could do something new.  Both images and spectra should be dealt with as
 > components of VO data access.



Hi Niall,

Here's the ad hoc solution chosen for the AVO science demo. The SEDs 
were expressed as a VOTable which got dynamically created by 
Aladin/VizieR and handed over to a little SED plot utility:

--------------

For each object there is a <TABLE ID="" name=""> element. The 'ID' 
attribute is 'abused' for event handling/display purposes between some 
java components. The optional 'name' attribute contains a catalog name 
and object identifier taken from VizieR/CDS.
E.g.: <TABLE ID="528661881" name="II/234/ubvrijk 19311">

Each TABLE contains at least 2 FIELD elements (flux and frequency) with 
optional error column(s). Arbitrary further columns are ignored.

For the sake of the demo we agreed to use the following UCDs:
Flux (Jy)             : PHOT_FLUX_DENSITY
error in flux         : ERROR
central frequency (Hz): OBS_FREQUENCY
error in frequency    : ERROR

The following FIELD attributes are used:
{ name, ucd, unit, datatype }
Attribute 'precision' was specified, but not actually used.

E.g.: <FIELD name="frequency" ucd="OBS_FREQUENCY" unit="Hz" 
datatype="float" precision="E5"></FIELD>

-------------

Maybe it's useful to look at the user requirements to understand the 
rationale for above solution:
http://www.euro-vo.org/internal/Avo/AvoSoftwareRepos/sed_urd.txt

Obviously there are a number of assumptions built in but we are 
interested in finding a more general convention.
Some improvements would be straight forward like supporting different 
units or allow to choose from arbitrary UCDs.

-------------

Other steps are more tricky: An important step not described in the 
VOTable is how to convert magnitudes given in some VizieR catalog to 
flux density as required by the SED plotter. For the AVO demo it was 
done only for some selected catalogs by consulting relevant publications 
and looking up zero points in some FITS headers.

Markus



From - Tue Apr  1 14:31:48 2003
X-UIDL: 3e5baf65000003a6
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h31CTQl7006134;
	Tue, 1 Apr 2003 14:29:26 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h31CTPK09639;
	Tue, 1 Apr 2003 14:29:25 +0200 (MEST)
Received: from maroon.csi.cam.ac.uk(131.111.8.2) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAHaaq0s; Tue, 1 Apr 03 14:29:24 +0200
Received: from cass41.ast.cam.ac.uk ([131.111.69.186])
	by maroon.csi.cam.ac.uk with esmtp (Exim 4.12)
	id 190KqE-0000eN-00; Tue, 01 Apr 2003 13:26:14 +0100
Received: from cappc33.ast.cam.ac.uk (cappc33 [131.111.69.212])
	by cass41.ast.cam.ac.uk (8.12.8+Sun/8.12.8) with ESMTP id h31CQD8Z014397;
	Tue, 1 Apr 2003 13:26:13 +0100 (BST)
Date: Tue, 1 Apr 2003 13:04:54 +0100 (BST)
From: Nicholas A Walton <naw@ast.cam.ac.uk>
To: dal@ivoa.net, <dm@ivoa.net>, <grid@ivoa.net>, <interop@ivoa.net>,
   <registry@ivoa.net>, <ucd@ivoa.ne>, <voql@ivoa.net>, <votable@ivoa.net>
cc: ivoa@ivoa.net
Subject: Cambridge, UK, May 12-16, 2003, InterOperability meetings
Message-ID: <Pine.LNX.4.44.0304011302220.1204-100000@cappc33.ast.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status:   

Dear All,

		** registration now open at **
http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003

please check http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003 and
related links for emerging details as to the upcoming InterOp meetings in
Cambridge.

I provide details and links to hotels on the above page. I would advise
that you consider booking your accommodation as soon as possible.

Yours, Nic Walton


========================================================================
Dr N. A. Walton
(AstroGrid Project Scientist)   Tel:   +44 1223 337503
Institute of Astronomy          FAX:   +44 1223 337523
University of Cambridge         WWW:   http://www.astrogrid.org
Madingley Road                  WWW:   http://www.ast.cam.ac.uk/~naw
Cambridge, CB3 0HA              email: naw@ast.cam.ac.uk
========================================================================



From - Wed Apr  2 18:17:51 2003
X-UIDL: 3e5baf6500000408
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h32FcxBf022589
	for <dal@ivoa.net>; Wed, 2 Apr 2003 18:15:22 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h32FO3N27175
	for <dal@ivoa.net>; Wed, 2 Apr 2003 17:24:03 +0200 (MEST)
Received: from dns.noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAaOa4d1; Wed, 2 Apr 03 17:24:01 +0200
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 6972736; Wed, 02 Apr 2003 08:22:44 -0700
Date: Wed, 2 Apr 2003 08:26:37 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: Markus Dolensky <Markus.Dolensky@eso.org>
cc: Jonathan McDowell <jcm@head-cfa.cfa.harvard.edu>,
   IVOA data access layer <dal@ivoa.net>, <arots@head-cfa.cfa.harvard.edu>
Subject: Re: supporting spectroscopy
In-Reply-To: <3E8AE437.9010807@eso.org>
Message-ID: <Pine.LNX.4.44.0304020817230.10904-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Hi Markus -

On Wed, 2 Apr 2003, Markus Dolensky wrote:
> As you know in mid May there will be an interoperability meeting in 
> Cambridge (http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003).
> 
> In preparation to this event I'd like to gather information on how to 
> extend Simple Image Access to spectroscopy including SEDs.

Everyone it seems is interested in extending SIA in various ways.  Arnold
has been looking at some aspects of this and it would be reasonable for
you to do so too.  Roy and others are interested in the problem of object
identification and replica management.  CDS and others have made a number
of suggestions as well.  A reasonable approach might be to think about
what we would all like to do and discuss it in the upcoming meetings.

Below is some email I posted within NVO yesterday in preparation for
our upcoming team meeting here (which is tomorrow).  This is just an
attempt to summarize many of the things we could do - we probably can't
do them all, so we should decide what our priorities are.

	- Doug


>From dtody@nrao.edu Wed Apr  2 08:19:09 2003
Date: Tue, 1 Apr 2003 13:30:37 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
To: metadata@us-vo.org, tech@us-vo.org, pmr@us-vo.org
Subject: Call for proposals for SIAP Version 2

Arnold - Thanks for the SAO perspective on the extensions needed to SIA
to better handle your data.  I would like to open this up for broader
discussion and solicit suggestions from everyone for further enhancement
to SIA.

We will have at least one more version of SIA before it is replaced by
(or folded into) a more general facility.  In considering what to add we
should ask ourselves the following question: what do we most need to add
to SIA to support our VO science prototypes over, say, the next year?

It is easy to come up with a list of features far longer than we can expect
to agree upon in the near future, or get service providers to implement.
We need to identify the highest priority additions, and in keeping with
the philosophy of SIA, find a reasonably simple way to implement these.
It must remain easy for a service provider to put up a basic SIA service.
The full data discovery and data access problem cannot be fully addressed
in a prototype and will ultimately require technology (e.g., a metadata
framework, updated UCDs, data models, etc.) which does not yet exist.

Possible extensions to SIA will be discussed (along with other data
access issues) at the NVO team meeting in Pasadena later this week,
at the IVOA interoperability workshop at Cambridge next month, and in
the various working groups.  A reasonable plan would be to try to reach
agreement so that we can proceed with the next version by late May,
after the interoperability workshop.

Below is a strawman list of possible enhancements to the next version
of SIA.  This is intended only to provoke further discussion.  What else
is needed?  What are the priorities?  We can hopefully update the list
after we discuss this in Pasadena at the end of the week.     - Doug



			    Simple Image Access
		      Potential version 2 enhancements
				April 2003



Registry Support

    This is my personal highest priority for SIA.  Currently there is
    no SIA registry - the existing Web list is incomplete and does not
    list most of the implementations already out there.  Service
    discovery is needed to actually use a VO service like SIA.


Image Attributes

    The following are all high priority candidates for additions to the
    image metadata and/or query parameters to better characterize the
    images dealt with by SIA.

    Image provenance and identification

	Needed to identify images, or select images from a particular 
	source.  Minimum requirements:

	data collection identifier (e.g., survey name)
	dataset identifier (uniquely defined within data collection)
	
	Issue: How to describe virtual data and relate it back to
	physical datasets (e.g., relate an image cutout back to the
	physical image it is derived from).  This gets complicated
	in the case of mosaics or other image combinations.

	Issue: Recognition and handling of data replicas.  We have
	to be able to uniquely identify datasets within some namespace
	before we can do anything with replicas.  What constitutes
	a replica may not be clear.

	(This issue has been extensively discussed in the mail groups)

    Spectral bandpass (already present)

	Necessary to select images given the spectral band, or to
	select the individual planes of an image cube.

	A version of this is already present in SIA and could be used
	as the model for other image attributes.

    Spatial bandpass

	This would be useful for radio data where only a range of
	spatial frequencies may be present in the image.  Analogous
	to spectral bandpass and could be handled in a similar fashion.

    Resolution

	The approximate spatial resolution of the image.  This can be
	problematic if one tries to specify it too precisely, but for
	multiwavelength data analysis even a crude estimate of the
	spatial resolution can be very useful.

    Limiting flux

	Sensitivity, limiting magnitude or flux, or flux / rms.  Exposure
	time is not useful here as it does not provide an absolute measure
	of the detection limit of the image.  A wavelength-independent
	representation is needed.

    Image type

	If we extend the data model supported by SIA (see below) we might
	want to add an image type attribute to specify the type of "image",
	e.g., 2D sky projection, sky projection data cube, spectra, and
	so forth.  This issue was discussed earlier in connection with
	raw and calibrated data and we decided to support only calibrated
	data, but we could revisit the issue.


Image Query

    All of the image attribute parameters are potentially useful as
    query parameters.

    POS,SIZE as currently defined is simple but is not well defined
    at the pole.  This is only worth fixing (for SIA) if we can find a
    simple solution.  POS is used mainly to define the query region - the
    actual WCS image footprint given in the returned metadata can always
    be used by the client to select the actual images to be retrieved.

    It might be nice to be able to specify the coordinate system -
    however any such query generalization places an extra burden on
    service providers.  The alternative is to specify a larger region in
    ICRS coordinates and refine the image selection on the client side.
    Region rotation is currently handled in the same way.

    It might be nice to have the ability to simultaneously query multiple
    regions.



Data Model

    2D sky images

	Currently supported.  We need to characterize the data better
	as discussed under Image Attributes above.

    Spectral data cubes

	Do we want to improve support for spectral data cubes?	What is
	required?  Probably the most useful option would be the ability to
	use a bandpass parameter to select a particular band to be returned.

    Spectra

	Support for spectra could be added to SIA - but this could get
	complicated.  In what format should the spectra be returned,
	FITS or XML?  Currently SIA is flexible in the format of the
	data returned.	If most of the complexity of spectra is left
	to the output dataset then it could be possible to discover and
	retrieve spectra using SIA.  It might be necessary to return only
	some restricted metadata in the VOTable, similar to what is done
	for images, with the real spectral metadata being returned in the
	spectral dataset.  More ambitious schemes are possible of course.

    Event lists

	For most VO usage event list data is probably most useful if
	rendered into an image by the image service.  It might be useful
	to be able to pass through event list specific image-generation
	parameters to the service (e.g., a time filter) but it could
	be difficult to standardize anything more than a pass-through
	mechanism.

	In some cases (as Arnold suggests) it could be useful to retrieve
	the actual event list as a table, but this could get complicated.
	Currently SIA targets calibrated data, not raw data.  Is there
	a standard export format which we could use?  Handling event
	data can be difficult due to the complexity and to instrument
	dependencies.  In any case, it would not be difficult for SIA
	to use image metadata to characterize event data and provide an
	access reference, with the format of the data left unspecified.

    Visibility data

	Most of the comments for event lists apply here as well.
	SIA could be used to retrieve this data but we have to ask how
	useful this would be, compared to the archive access mechanisms
	already available for retrieval of raw data.  In the VO context
	it is probably more interesting to look at on-the-fly calibration
	and imaging, returning generated images to the client.	This can
	be done even with the current SIA.


Access Issues

    Resource and service metadata

	This needs further work in connection with the work on registries.
	Further information on coverage is needed, as well as more
	complete service specific metadata.  The service should be able
	to completely describe itself and the service registry should
	query the service to obtain all information to be cached in the
	registry.

    Protocols

	Currently we are using a URL-based scheme.  Do we want to
	add a web services-based protocol?  This is certainly doable,
	but would our client software be able to do anything useful
	with the data?

    Staging and messaging

	The interface contains a preliminary specification for this
	but thus far it has not been needed and has not been used.

    Replica identification and selection

	Is this an image metadata issue, or an access issue, or both?

    Authentication

	Currently we are deferring this - it should be possible to add it
	later without changing the current interface, which is data centric.




From - Wed Apr  2 15:26:50 2003
X-UIDL: 3e5baf65000003ff
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h32DN2pw018206;
	Wed, 2 Apr 2003 15:23:02 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h32DPoF29680;
	Wed, 2 Apr 2003 15:25:50 +0200 (MEST)
Message-ID: <3E8AE437.9010807@eso.org>
Date: Wed, 02 Apr 2003 15:23:03 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head-cfa.cfa.harvard.edu>,
   IVOA data access layer
 <dal@ivoa.net>, arots@head-cfa.cfa.harvard.edu
Subject: supporting spectroscopy
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Hi,

As you know in mid May there will be an interoperability meeting in 
Cambridge (http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003).

In preparation to this event I'd like to gather information on how to 
extend Simple Image Access to spectroscopy including SEDs.

Arnold:
Somebody said you are preparing a new version of the "Simple Image 
Access Prototype Specification". I wonder whether this is true since 
Doug and Ray appeared as the original authors? Should we base a possible 
extension for spectra on version 1.0 
(http://www.us-vo.org/news/simspec.html) of this document?

Jonathan:
Do the data modelers already have a definition for spectra/SEDs?
Should we use your document about "Bandpasses" as a reference, for UCDs, 
etc.?

In general:
Is anybody already working on this aspect?

Cheers,
Markus

+---
| Markus Dolensky   Mailto:Markus.Dolensky@eso.org
| AVO Technical Lead          Web: www.euro-vo.org
| Voice: ++49 89 32006/261  Fax: ++49 89 32006/480
+---

From - Wed Apr  2 19:11:53 2003
X-UIDL: 3e5baf6500000411
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h32H6t8Z004662
	for <dal@ivoa.net>; Wed, 2 Apr 2003 19:10:18 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h32G2VW28967
	for <dal@ivoa.net>; Wed, 2 Apr 2003 18:02:31 +0200 (MEST)
Received: from dns.noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAuiaGK4; Wed, 2 Apr 03 18:02:30 +0200
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 6973144; Wed, 02 Apr 2003 09:01:13 -0700
Date: Wed, 2 Apr 2003 09:04:41 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: Steve Lowe <slowe@cfa.harvard.edu>
cc: metadata <metadata@us-vo.org>, <dal@ivoa.net>
Subject: Re: Call for proposals for SIAP Version 2
In-Reply-To: <3E8AFB5F.5070102@cfa.harvard.edu>
Message-ID: <Pine.LNX.4.44.0304020833240.10904-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status:   

Hi Steve -

Part of the concept of SIA (or cone search) is that a client can send
the same basic query to a range of services and expect to get something
reasonable back.  The more advanced query features, e.g., the image
generation parameters, may not be supported by all services, and this can
be specified in the service metadata, queried in registries, and so forth.
But things like POS,SIZE,FORMAT are part of the most basic query and
anything we put in there should be supported (or at least accepted)
by all conformant services.

We can consider extending POS,SIZE further though.  Part of the reason
for making POS a string was to make it easier to do this sort of thing in
the future.  Galactic coordinates are pretty important and adding support
for these to POS is a reasonable thing to consider.  The broader question
is do we want to generalize the query region specification, and if so
what are the most important features to add?  ASU for example specifies
a more general syntax, see http://vizier.u-strasbg.fr/doc/asu.html.

With VO a question one always has to ask is if we are defining a user
interface or an internal Grid infrastructure interface.  If it is a user
interface we might want to load it up with lots of features to make it
as easy as possible for the user (or client program etc.).  If we are
doing this for one or a few sites and control the implementation it is
easy to do so.  If it is an internal service interface it is generally
simpler to include only what is needed for functional reasons, leaving
it up to clients to build the feature-rich user interface.  I think the
VO services are infrastructure, not user interfaces.

With that said, POS is very limited at present, to the point where there
are some functional limitations, and we could consider some enhancements.

Cheers,

	- Doug


On Wed, 2 Apr 2003, Steve Lowe wrote:
> Doug Tody wrote:
> 
> >It is easy to come up with a list of features far longer than we can expect
> >to agree upon in the near future, or get service providers to implement. 
> >
> ...
> 
> >It must remain easy for a service provider to put up a basic SIA service.
> >  
> >
> I think part of the idea is to say how some of these concepts can be 
> specified, but without requiring that all service providers implement 
> all elements. This could actually make buy-in easier. For example, a 
> service that has all its data and catalogs in galactic coordinates would 
> not have to convert query arguments from ICRS if it didn't want to. This 
> sort of capability in prototypes might provide a model for client 
> software negotiating with archives that provide different types of data 
> and that place different constraints on queries.
> 
> A key requirement for this to work is that the service provider be able 
> to communicate to the client which query elements it can accept. This 
> will be part of the metadata service request (FORMAT=METADATA).
> 
> Steve

From - Wed Apr  2 19:51:53 2003
X-UIDL: 3e5baf6500000415
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h32HmR7J024025
	for <dal@ivoa.net>; Wed, 2 Apr 2003 19:48:27 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h32HmRl15141
	for <dal@ivoa.net>; Wed, 2 Apr 2003 19:48:27 +0200 (MEST)
Received: from mailhost.cacr.caltech.edu(131.215.145.180) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAX7aiKD; Wed, 2 Apr 03 19:48:26 +0200
Received: from SARA (sara.cacr.caltech.edu [131.215.145.107])
	by mailhost.cacr.caltech.edu (8.9.3/8.9.1) with SMTP id JAA18272;
	Wed, 2 Apr 2003 09:44:59 -0800 (PST)
Message-ID: <06ce01c2f93f$b5889c00$6b91d783@cacr.caltech.edu>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: "Doug Tody" <dtody@nrao.edu>, "Steve Lowe" <slowe@cfa.harvard.edu>
Cc: "metadata" <metadata@us-vo.org>, <dal@ivoa.net>
References: <Pine.LNX.4.44.0304020833240.10904-100000@localhost.localdomain>
Subject: Re: Call for proposals for SIAP Version 2
Date: Wed, 2 Apr 2003 09:45:54 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Status:   

>  Galactic coordinates are pretty important and adding support
> for these to POS is a reasonable thing to consider.

The more complicated is the specification of conesearch/SIA, the smaller the
number of implementations! It is the NVO that should build the middleware --
so that users get a rich set of services, but the entrance cost for
publishers is low low low.

One way to do the galactic coordinates is to specify SIA in terms of a
single coordinate system (as it is now), and have a middleware service to
make the coordinate conversion, which in turn calls the elementary service.

> The broader question
> is do we want to generalize the query region specification,

Similarly, we could have an elementary service specification that uses only
disks or rectangles, and have middleware to deal with complex regions
through multiple calls to the elementary service.

Just as programmers in the 1960's learned to combine subroutines as
components, so the Holy Grail of Web Services is to combine services as
components. (Your comments welcome).

>  ASU for example specifies
> a more general syntax, .

Let us ask a specific question then: is is possible to convert an arbitrary
conesearch service to an ASU service through appropriate middleware?

> > A key requirement for this to work is that the service provider be able
> > to communicate to the client which query elements it can accept. This
> > will be part of the metadata service request (FORMAT=METADATA).

There is a very general type of conversation that I think we should include
as part of our service specification. Once we can implement this in a
general way, it covers a lot of ground.

Waiter: What type of toast?
Customer: What do you have?
Waiter: White, wheat, rye, ....
Customer: Wheat

Note that lines 2 and 3 can be omitted if the customer already knows the
list of options.

Roy

From - Thu Apr  3 17:11:56 2003
X-UIDL: 3e5baf650000043b
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h33FBLYB006881
	for <dal@ivoa.net>; Thu, 3 Apr 2003 17:11:21 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h33FBKV19383
	for <dal@ivoa.net>; Thu, 3 Apr 2003 17:11:20 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAWvaW2L; Thu, 3 Apr 03 17:11:19 +0200
Received: from cfa.harvard.edu (pioneer [131.142.184.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h33F3fid011847;
	Thu, 3 Apr 2003 10:03:41 -0500 (EST)
Message-ID: <3E8C4D4C.7070506@cfa.harvard.edu>
Date: Thu, 03 Apr 2003 10:03:40 -0500
From: Steve Lowe <slowe@cfa.harvard.edu>
Organization: SAO / CfA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Good <jcg@ipac.caltech.edu>
CC: Roy Williams <roy@cacr.caltech.edu>, Doug Tody <dtody@nrao.edu>,
   metadata
 <metadata@us-vo.org>, dal@ivoa.net
Subject: Re: Call for proposals for SIAP Version 2
References: <Pine.LNX.4.44.0304020833240.10904-100000@localhost.localdomain> <06ce01c2f93f$b5889c00$6b91d783@cacr.caltech.edu> <3E8B3450.62B2C6F7@ipac.caltech.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

John Good wrote:

>Roy -
>
>  
>
>>> Galactic coordinates are pretty important and adding support
>>>for these to POS is a reasonable thing to consider.
>>>      
>>>
>>The more complicated is the specification of conesearch/SIA, the smaller the
>>number of implementations! It is the NVO that should build the middleware --
>>so that users get a rich set of services, but the entrance cost for
>>publishers is low low low.
>>
>>One way to do the galactic coordinates is to specify SIA in terms of a
>>single coordinate system (as it is now), and have a middleware service to
>>make the coordinate conversion, which in turn calls the elementary service.
>>    
>>
>
>This is dead wrong.   Coordinate syntax parsing, coordinate transforms,
>and polygonal constraints (which includes the "cone search" as a single-
>constraint subset) are all straightforward and should be an integral part
>of any server-side search engine (image or catalog).  NVO should be
>promulgating knowlege on how to do this (and portable code snippets,
>where appropriate), not characterizing it as a complex issue that needs
>third-party middleware.
>  
>
Coordinate transforms are not difficult, but they're not trivial to get 
right either. This is especially so if we depart from the "distant" sky 
and try to specify more local observations for which the observing 
position is important.

While I generally agree with the philosophy of providing know-how rather 
than software, I think realistically it will be beneficial to keep the 
buy-in cost low as Roy suggests. Consider that the user receives the 
direct benefit in acquiring data from a provider. The provider's 
benefit, if any, may be more indirect, such as community publicity or 
favor of the funding agencies. This is an argument for making life as 
easy as possible for the provider.

I don't think portable code snippets will do, I think you'd need a 
supported software library.

Whatever the ultimate decision on whether clients or providers have to 
support multiple coordinate systems, for now this capability can be used 
as a model to examine client-provider negotiation.

Steve

-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe@cfa.harvard.edu
1-617-496-1661



From - Fri Apr  4 01:21:56 2003
X-UIDL: 3e5baf6500000446
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h33NIvGa026915
	for <dal@ivoa.net>; Fri, 4 Apr 2003 01:18:57 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h33NIvw12783
	for <dal@ivoa.net>; Fri, 4 Apr 2003 01:18:57 +0200 (MEST)
Received: from rain.ipac.caltech.edu(134.4.10.130) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAY7aW9y; Fri, 4 Apr 03 01:18:55 +0200
Received: from rain.ipac.caltech.edu (localhost [127.0.0.1])
	by rain.ipac.caltech.edu (8.11.7/8.11.6) with ESMTP id h33NBOZ26490
	for <dal@ivoa.net>; Thu, 3 Apr 2003 15:11:24 -0800 (PST)
Received: from ipac.caltech.edu (oasis.ipacds.ipac.caltech.edu [134.4.70.173])
	by rain.ipac.caltech.edu (8.11.7/8.11.6) with ESMTP id h33NBKp26469;
	Thu, 3 Apr 2003 15:11:20 -0800 (PST)
Message-ID: <3E8CBF98.595E3B6F@ipac.caltech.edu>
Date: Thu, 03 Apr 2003 15:11:20 -0800
From: John Good <jcg@ipac.caltech.edu>
Organization: IPAC / Caltech
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Lowe <slowe@cfa.harvard.edu>
CC: Roy Williams <roy@cacr.caltech.edu>, Doug Tody <dtody@nrao.edu>,
   metadata <metadata@us-vo.org>, dal@ivoa.net
Subject: Re: Call for proposals for SIAP Version 2
References: <Pine.LNX.4.44.0304020833240.10904-100000@localhost.localdomain> <06ce01c2f93f$b5889c00$6b91d783@cacr.caltech.edu> <3E8B3450.62B2C6F7@ipac.caltech.edu> <3E8C4D4C.7070506@cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   


Steve -

> Coordinate transforms are not difficult, but they're not trivial to get
> right either. This is especially so if we depart from the "distant" sky
> and try to specify more local observations for which the observing
> position is important.
>
> While I generally agree with the philosophy of providing know-how rather
> than software, I think realistically it will be beneficial to keep the
> buy-in cost low as Roy suggests. Consider that the user receives the
> direct benefit in acquiring data from a provider. The provider's
> benefit, if any, may be more indirect, such as community publicity or
> favor of the funding agencies. This is an argument for making life as
> easy as possible for the provider.
>
> I don't think portable code snippets will do, I think you'd need a
> supported software library.

I agree and there are at least a couple of coordinate transform libraries
already.  The code snippets I was referring to would be examples of
how to do the polygon, etc. constraint filtering.


> Whatever the ultimate decision on whether clients or providers have to
> support multiple coordinate systems, for now this capability can be used
> as a model to examine client-provider negotiation.

Since providers can be readily taught how to provide more complete
spatial filtering, I think this is the wrong place to experiment on
negotiation (at least until we get to more complex regions).

I would say a more relevant area for negotiation would be related
to query engine capabilities, particularly regarding the ability to place
additional relational constraints on metadata that passes the
positional filter.

For instance, our "Cone Search" service already allows for the full
range of positional constraints I described (and which I think can be
implemented universally).  It also allows for generic SQL constraints
("WHERE" clauses) on any of the fields in the table.  Now, for those
implementations which are not build on top of DBMS technology,
I can see that this ability could be difficult.  They might have no
such filtering or might only be able to filter on something like magnitude
ranges for a specific field.

I would like to see this ability called out as a part of both a more general
catalog search (superceding the Cone Search) and as an extension of the
SIA protocol.  Here there is  definitely a need for client-provider
negotiation, not just on whether this capability exists but then on the
"data dictionary" associated  with the fields that can be constrained
(or "SELECT"ed for that matter).

We provide the data dictionary information as a separate XML
service but it be envisioned as part of the same protocol suite.

- John

From - Fri Apr  4 02:26:56 2003
X-UIDL: 3e5baf6500000447
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h340PfGa023132
	for <dal@ivoa.net>; Fri, 4 Apr 2003 02:25:41 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h340PfA14829
	for <dal@ivoa.net>; Fri, 4 Apr 2003 02:25:41 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAaMaG9C; Fri, 4 Apr 03 02:25:40 +0200
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h340I2id007282;
	Thu, 3 Apr 2003 19:18:02 -0500 (EST)
From: Arnold Rots <arots@head-cfa.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.11.1/8.11.1) id h340I2207647;
	Thu, 3 Apr 2003 19:18:02 -0500 (EST)
Message-Id: <200304040018.h340I2207647@xebec.cfa.harvard.edu>
Subject: Re: Call for proposals for SIAP Version 2
In-Reply-To: <3E8B3450.62B2C6F7@ipac.caltech.edu>
To: John Good <jcg@ipac.caltech.edu>
Date: Thu, 3 Apr 2003 19:18:02 -0500 (EST)
CC: Roy Williams <roy@cacr.caltech.edu>, Doug Tody <dtody@nrao.edu>,
   Steve Lowe <slowe@cfa.harvard.edu>, metadata <metadata@us-vo.org>,
   dal@ivoa.net
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

John Good wrote:
> 
> 
> Roy -
> ...
> 
> This is dead wrong.   Coordinate syntax parsing, coordinate transforms,
> and polygonal constraints (which includes the "cone search" as a single-
> constraint subset) are all straightforward and should be an integral part
> of any server-side search engine (image or catalog).  NVO should be
> promulgating knowlege on how to do this (and portable code snippets,
> where appropriate), not characterizing it as a complex issue that needs
> third-party middleware.
> 

Though I in general agree with this, the comments below are too
restrictive.  A convex polygon may be sufficient for queries, but
certainly not for general applications.  And one has to be careful
when dealing with projections.  Great circles are straight lines in
TAN projections, but not in any other.  Concave polygons and regions
with holes will need to be dealt with.

> 
> ...
> 
> I admit to a bias here.  I have yet to see a need for anything more complicated
> that a convex polygon on the sky as a region definition (i.e. no annuli or other
> 
> regions with holes).  With that constraint, I maintain that the following are
> all
> equivalent (in that a single location-filtering library can handle them all):
> 
>    o  Convex polygon in any coordinate system.  This is just
>        a set of planes cutting the sphere.  Usually great circle
>        planes but just as easily small circles (e.g. latitude lines)
> 
>    o  Point-radius "cone" searches (since this is just a single plane)
> 
>    o  Box on the sky (if you assume great circles connecting the
>        the corners of the box, this is both a four sided polygon
>        as above (you just parameterize it differently) and is exactly
>        the same as the coverage of a Gnomonic projection (TAN)
>        image of the same size.
> 
> For many real-world images, connecting corners by great circles is close
> enough for coverage checking, so I would maintain that a FITS header
> (translated to a box) can also be used as a region definition.
> 
> 
> ...
> 
> - John
> 
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From - Fri Apr  4 10:31:56 2003
X-UIDL: 3e5baf650000044f
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <cgp@star.le.ac.uk>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h348RjGa028293
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 10:27:45 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h348Rjo26075
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 10:27:45 +0200 (MEST)
Received: from apollo.le.ac.uk(143.210.16.125) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAATgaq7Y; Fri, 4 Apr 03 10:27:44 +0200
Received: from [143.210.36.58] (helo=mail.star.le.ac.uk)
	by apollo.le.ac.uk with smtp (Exim 4.14)
	id 191MUG-0000zm-JX
	for Markus.Dolensky@eso.org; Fri, 04 Apr 2003 09:23:48 +0100
Received: (qmail 8863 invoked from network); 4 Apr 2003 08:24:10 -0000
Received: from peneca.star.le.ac.uk (143.210.36.224)
  by mail.star.le.ac.uk with SMTP; 4 Apr 2003 08:24:10 -0000
Date: Fri, 4 Apr 2003 09:23:48 +0100 (BST)
From: Clive Page <cgp@star.le.ac.uk>
To: "'Markus Dolensky'" <Markus.Dolensky@eso.org>
cc: Tony Linde <ael@star.le.ac.uk>, "'Bob Mann'" <rgm@roe.ac.uk>,
   Keith Noddle <ktn@star.le.ac.uk>
Subject: RE: IVOA WG data access layer
In-Reply-To: <007f01c2fa21$710716f0$cc24d28f@brolga>
Message-ID: <Pine.LNX.4.44L0.0304040920510.5887-100000@peneca.star.le.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -104.4 (-----------------------------------------)
X-Scanner: exiscan for exim4 *191MUG-0000zm-JX*Wu4rqPJmexY*
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

On Thu, 3 Apr 2003, Tony Linde wrote:

> Offhand I can suggest Clive Page and Bob Mann as being possibly interested
> (copied on this). I'll let them reply if they want to sign up. I'll also
> announce the group to see if anyone else is interested. Why not ask on the
> mailing list?

Markus

Yes, I guess I should volunteer for this as at present I am leading the
AstroGrid workpackage on data access etc.

> > Are you interested in this SIA/DAL business or would you

Sorry, the acronym SIA/DAL is not one that my brain translates instantly -
any hints?

> > For the current status please refer to
> > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDA> L

I looked at this page but got: This Wiki topic does not exist yet

Regards


-- 
Clive Page,
Dept of Physics & Astronomy,
University of Leicester,    Tel +44 116 252 3551
Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311

From - Fri Apr  4 11:06:56 2003
X-UIDL: 3e5baf6500000450
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <ael@star.le.ac.uk>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3493XGa013560
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 11:03:33 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3493Xm27503
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 11:03:33 +0200 (MEST)
Received: from mta06-svc.ntlworld.com(62.253.162.46) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA3IaWT1; Fri, 4 Apr 03 11:03:32 +0200
Received: from brolga ([213.105.123.90]) by mta06-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20030404090152.WAKN2033.mta06-svc.ntlworld.com@brolga>;
          Fri, 4 Apr 2003 10:01:52 +0100
Reply-To: <ael@star.le.ac.uk>
From: "Tony Linde" <ael@star.le.ac.uk>
To: "'Clive Page'" <cgp@star.le.ac.uk>,
   "'Markus Dolensky'" <Markus.Dolensky@eso.org>
Cc: "'Bob Mann'" <rgm@roe.ac.uk>, "'Keith Noddle'" <ktn@star.le.ac.uk>
Subject: RE: IVOA WG data access layer
Date: Fri, 4 Apr 2003 10:01:57 +0100
Organization: University of Leicester
Message-ID: <009401c2fa88$d8d6fea0$cc24d28f@brolga>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <Pine.LNX.4.44L0.0304040920510.5887-100000@peneca.star.le.ac.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

> Sorry, the acronym SIA/DAL is not one that my brain 
> translates instantly - any hints?

SIAP: Simple Image Access Protocol: 
- one of the NVO efforts:
  http://www.us-vo.org/news/simspec.html

DAL: Data Access Layer:
- one of the standards areas being tackled by IVOA workgroups (along with
Registry, ...)

> > > For the current status please refer to 
> > > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDA> L
> 
> I looked at this page but got: This Wiki topic does not exist yet

Probably because the last letter was chopped off, try:
  http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDAL

Cheers,
Tony. 

> -----Original Message-----
> From: Clive Page [mailto:cgp@star.le.ac.uk] 
> Sent: 04 April 2003 09:24
> To: 'Markus Dolensky'
> Cc: Tony Linde; 'Bob Mann'; Keith Noddle
> Subject: RE: IVOA WG data access layer
> 
> 
> On Thu, 3 Apr 2003, Tony Linde wrote:
> 
> > Offhand I can suggest Clive Page and Bob Mann as being possibly 
> > interested (copied on this). I'll let them reply if they 
> want to sign 
> > up. I'll also announce the group to see if anyone else is 
> interested. 
> > Why not ask on the mailing list?
> 
> Markus
> 
> Yes, I guess I should volunteer for this as at present I am 
> leading the AstroGrid workpackage on data access etc.
> 
> > > Are you interested in this SIA/DAL business or would you
> 
> Sorry, the acronym SIA/DAL is not one that my brain 
> translates instantly - any hints?
> 
> > > For the current status please refer to 
> > > http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDA> L
> 
> I looked at this page but got: This Wiki topic does not exist yet
> 
> Regards
> 
> 
> -- 
> Clive Page,
> Dept of Physics & Astronomy,
> University of Leicester,    Tel +44 116 252 3551
> Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311
> 

From - Fri Apr  4 13:25:19 2003
X-UIDL: 3e5baf6500000459
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34BOhGa016127;
	Fri, 4 Apr 2003 13:24:43 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h34BRYF10126;
	Fri, 4 Apr 2003 13:27:34 +0200 (MEST)
Message-ID: <3E8D6B7D.3030104@eso.org>
Date: Fri, 04 Apr 2003 13:24:45 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Clive Page <cgp@star.le.ac.uk>
CC: dal@ivoa.net, Keith Noddle <ktn@star.le.ac.uk>
Subject: Re: IVOA WG data access layer
References: <Pine.LNX.4.44L0.0304041111500.6471-100000@peneca.star.le.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Clive, my view is pretty much the same.

Clive Page wrote:
> I assume that this group assumes that the VOTable format solves the
> problems of returning tabular data (for the present).  I would have
> thought that spectroscopic and time series data could also be expressed in
> tabular form, so the extension of VOTable to cover them was just a matter
> of adding the necessary metadata, or is this just betraying my lack of
> experience in these areas?

Indeed, one could create some VOTable templates with UCDs that describe 
spectra, SEDs, you name it. The actual data could be either embedded in 
<TABLEDATA> elements or in some external FITS table extension. It might 
not be a huge challenge.


> I have a question also about the scope of this WG: is it just for the data
> returned from an archive query, or does it include the query format also?
> I note that the SIA(P) spec does specify the query format (section 4).  I
> think we discussed in the Strasbourg meeting last year whether VOTable
> should cover queries or not, and decided against as it is a difficult area
> in which to reach agreement.  But the question of an AQL (or VOQL) must be
> tackled some time, and we are interested in it.

The actual query could be based on a TBD VOQL for which there is another 
WG. In case you are not familiar with the 6 WGs. There's a Wiki page for 
each of them here http://www.ivoa.net/intranet/ as well as a one mailing 
list for each {dm,dal,registry,ucd,voql,votable}@ivoa.net (and this 
message is CC'd to the relevant one). Data modelers (DM) provide the 
necessary definitions and data structures. The registry is our 
directory. Meta data are dealt with in the UCD group. VOQL provides a 
query mechanism and the data format is VOTable.

>>It looks like we'll have a WG meeting May 14, but probably we'll start
>>already on Tue May 13. It is really up to us. (Forget Nic's agenda - it
>>was just to make people start doing things, which worked as one can see.)
> 
> 
> OK, I am assuming that I shall have to be in Cambridge for nearly all that
> week (fortunately I live not too far away).

Yes, please.

Markus

+---
| Markus Dolensky   Mailto:Markus.Dolensky@eso.org
| AVO Technical Lead          Web: www.euro-vo.org
| Voice: ++49 89 32006/261  Fax: ++49 89 32006/480
+---

From - Fri Apr  4 13:36:56 2003
X-UIDL: 3e5baf650000045a
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <cgp@star.le.ac.uk>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34BWHGa019596
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 13:32:17 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34BWH403842
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 13:32:17 +0200 (MEST)
Received: from mailsend.le.ac.uk(143.210.16.129) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAqtaiGh; Fri, 4 Apr 03 13:32:16 +0200
Received: from [143.210.36.58] (helo=mail.star.le.ac.uk)
	by homer.le.ac.uk with smtp (Exim 4.14)
	id 191PMz-0006Js-Tv
	for Markus.Dolensky@eso.org; Fri, 04 Apr 2003 11:28:29 +0000
Received: (qmail 23454 invoked from network); 4 Apr 2003 11:28:51 -0000
Received: from peneca.star.le.ac.uk (143.210.36.224)
  by mail.star.le.ac.uk with SMTP; 4 Apr 2003 11:28:51 -0000
Date: Fri, 4 Apr 2003 12:28:29 +0100 (BST)
From: Clive Page <cgp@star.le.ac.uk>
To: Markus Dolensky <Markus.Dolensky@eso.org>
cc: dal@ivoa.net, Keith Noddle <ktn@star.le.ac.uk>
Subject: Re: IVOA WG data access layer
In-Reply-To: <3E8D6B7D.3030104@eso.org>
Message-ID: <Pine.LNX.4.44L0.0304041226270.7530-100000@peneca.star.le.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -104.4 (-----------------------------------------)
X-Scanner: exiscan for exim4 *191PMz-0006Js-Tv*gFZOKPvxwSg*
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

On Fri, 4 Apr 2003, Markus Dolensky wrote:

> The actual query could be based on a TBD VOQL for which there is another
> WG.

Yes, but the VOQL working group appears not yet to have got off the
ground, and the mailing list (to which I subscribe) has had very little
traffic.  Since these topics are quite closely related, it is hard to know
whether to deal with them separately or together.

-- 
Clive Page,
Dept of Physics & Astronomy,
University of Leicester,    Tel +44 116 252 3551
Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311

From - Fri Apr  4 13:51:57 2003
X-UIDL: 3e5baf650000045d
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34BlOGa026132
	for <dal@ivoa.net>; Fri, 4 Apr 2003 13:47:24 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34BlNc04460
	for <dal@ivoa.net>; Fri, 4 Apr 2003 13:47:23 +0200 (MEST)
Received: from mta01-svc.ntlworld.com(62.253.162.41) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA_IayTi; Fri, 4 Apr 03 13:47:22 +0200
Received: from brolga ([213.105.123.90]) by mta01-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20030404114540.HYEE6166.mta01-svc.ntlworld.com@brolga>
          for <dal@ivoa.net>; Fri, 4 Apr 2003 12:45:40 +0100
Reply-To: <ael@star.le.ac.uk>
From: "Tony Linde" <ael@star.le.ac.uk>
To: <dal@ivoa.net>
Subject: RE: IVOA WG data access layer
Date: Fri, 4 Apr 2003 12:45:45 +0100
Organization: University of Leicester
Message-ID: <00a501c2fa9f$bb295f30$cc24d28f@brolga>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <Pine.LNX.4.44L0.0304041226270.7530-100000@peneca.star.le.ac.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h34BldGa026221
Status:   

I guess this group should begin to state the requirements for a query
language based on its work but I agree that there is quite a lot of overlap.
The Registry group encompasses the registry query language/format.

Cheers,
Tony. 

> -----Original Message-----
> From: Clive Page [mailto:cgp@star.le.ac.uk] 
> Sent: 04 April 2003 12:28
> To: Markus Dolensky
> Cc: dal@ivoa.net; Keith Noddle
> Subject: Re: IVOA WG data access layer
> 
> 
> On Fri, 4 Apr 2003, Markus Dolensky wrote:
> 
> > The actual query could be based on a TBD VOQL for which there is 
> > another WG.
> 
> Yes, but the VOQL working group appears not yet to have got 
> off the ground, and the mailing list (to which I subscribe) 
> has had very little traffic.  Since these topics are quite 
> closely related, it is hard to know whether to deal with them 
> separately or together.
> 
> -- 
> Clive Page,
> Dept of Physics & Astronomy,
> University of Leicester,    Tel +44 116 252 3551
> Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311
> 


From - Fri Apr  4 13:56:57 2003
X-UIDL: 3e5baf650000045e
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34BrVGa028834
	for <dal@ivoa.net>; Fri, 4 Apr 2003 13:53:31 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34BrVl04824
	for <dal@ivoa.net>; Fri, 4 Apr 2003 13:53:31 +0200 (MEST)
Received: from mta01-svc.ntlworld.com(62.253.162.41) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAcuaWAj; Fri, 4 Apr 03 13:53:30 +0200
Received: from brolga ([213.105.123.90]) by mta01-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20030404115148.INEB6166.mta01-svc.ntlworld.com@brolga>
          for <dal@ivoa.net>; Fri, 4 Apr 2003 12:51:48 +0100
Reply-To: <ael@star.le.ac.uk>
From: "Tony Linde" <ael@star.le.ac.uk>
To: <dal@ivoa.net>
Subject: RE: IVOA WG data access layer
Date: Fri, 4 Apr 2003 12:51:53 +0100
Organization: University of Leicester
Message-ID: <00a601c2faa0$961cb3d0$cc24d28f@brolga>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <3E8D58D9.8010903@eso.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

I think the DAL has to look at all types of access to data whether querying
catalogues, accessing images, time series or spectra and any other type of
data access.

Or is the split intended to be: 

. VOQL addresses access to tabular data

. DAL addresses access to non-tabular data

Might work.

Cheers,
Tony. 

> -----Original Message-----
> From: Markus Dolensky [mailto:Markus.Dolensky@eso.org] 
> Sent: 04 April 2003 11:05
> To: ael@star.le.ac.uk
> Cc: 'Clive Page'; 'Bob Mann'; 'Keith Noddle'; Doug Tody
> Subject: Re: IVOA WG data access layer
> 
> 
> Hi Clive,
> 
> Tony thankfully already answered the questions.
> 
> I'm glad to hear that you'll augment our little group.
> Myself I'm referring to it as the DAL (data access layer) 
> working group 
> since Simple Image Access is neither very simple nor do we want to 
> restrict it to images. But since the only document about it so far 
> coined the term SIA it is more commonly used in the NVO world.
> 
> For AVO we would like to add support for spectroscopy in the near 
> future. Somebody else might want to look into time series 
> data and how 
> to access them.
> 
> It looks like we'll have a WG meeting May 14, but probably 
> we'll start 
> already on Tue May 13. It is really up to us. (Forget Nic's 
> agenda - it 
> was just to make people start doing things, which worked as 
> one can see.)
> 
> The scope of DAL is the first thing to clarify. But please 
> refer to http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDAL
> for now.
> 
> Cheers,
> Markus
> 
> +---
> | Markus Dolensky   Mailto:Markus.Dolensky@eso.org
> | AVO Technical Lead          Web: www.euro-vo.org
> | Voice: ++49 89 32006/261  Fax: ++49 89 32006/480
> +---
> 
> 
> 
> Tony Linde wrote:
> >>Sorry, the acronym SIA/DAL is not one that my brain
> >>translates instantly - any hints?
> > 
> > 
> > SIAP: Simple Image Access Protocol:
> > - one of the NVO efforts:
> >   http://www.us-vo.org/news/simspec.html
> > 
> > DAL: Data Access Layer:
> > - one of the standards areas being tackled by IVOA 
> workgroups (along 
> > with Registry, ...)
> > 
> > 
> >>>>For the current status please refer to
> >>>>http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDA> L
> >>>
> >>I looked at this page but got: This Wiki topic does not exist yet
> > 
> > 
> > Probably because the last letter was chopped off, try:
> >   http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDAL
> > 
> > Cheers,
> > Tony.
> 
> 

From - Fri Apr  4 15:11:58 2003
X-UIDL: 3e5baf6500000463
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34D9aGa003715;
	Fri, 4 Apr 2003 15:09:36 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h34DCRF12695;
	Fri, 4 Apr 2003 15:12:27 +0200 (MEST)
Message-ID: <3E8D8412.8050707@eso.org>
Date: Fri, 04 Apr 2003 15:09:38 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: dal@ivoa.net, Keith Noddle <ktn@star.le.ac.uk>
CC: Nicholas Walton <naw@ast.cam.ac.uk>, Bob Hanisch <hanisch@stsci.edu>
Subject: Re: IVOA WG data access layer
References: <00a501c2fa9f$bb295f30$cc24d28f@brolga>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

 > [...] Data modelers (DM) provide the
 > necessary definitions and data structures. The registry is our
 > directory. Meta data are dealt with in the UCD group. VOQL provides a
 > query mechanism and the data format is VOTable.

Hence, DAL will have interaction with ALL the other WGs. We should be 
prepared to give all of them input (requirements) and we should also be 
prepared to accept certain constraints to stay within the framework they 
(the other 5 WGs) are setting within their scope.

We need a plenary session in Cambridge ...

... in order to review the scope of all the WGs and to see whether 
things need some re-arrangement or not. That's why the chair of the POC 
is on the CC list.

Doug, Tony:
In that context it might be worthwhile trying to map the existing system 
architectures of NVO and Astrogrid*  with the  WG breakdown. If on top 
of that we also have the names of those who work on the individual parts 
of a project on one side as well as the applicable standards (WGs) on 
the other side we would then know who should keep in touch with whom.

Markus

*) Astrogrid is defining the AVO grid architecture





Tony Linde wrote:
> I guess this group should begin to state the requirements for a query
> language based on its work but I agree that there is quite a lot of overlap.
> The Registry group encompasses the registry query language/format.
> 
> Cheers,
> Tony. 
> 
> 
>>-----Original Message-----
>>From: Clive Page [mailto:cgp@star.le.ac.uk] 
>>Sent: 04 April 2003 12:28
>>To: Markus Dolensky
>>Cc: dal@ivoa.net; Keith Noddle
>>Subject: Re: IVOA WG data access layer
>>
>>
>>On Fri, 4 Apr 2003, Markus Dolensky wrote:
>>
>>
>>>The actual query could be based on a TBD VOQL for which there is 
>>>another WG.
>>
>>Yes, but the VOQL working group appears not yet to have got 
>>off the ground, and the mailing list (to which I subscribe) 
>>has had very little traffic.  Since these topics are quite 
>>closely related, it is hard to know whether to deal with them 
>>separately or together.
>>
>>-- 
>>Clive Page,
>>Dept of Physics & Astronomy,
>>University of Leicester,    Tel +44 116 252 3551
>>Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311

From - Fri Apr  4 15:26:56 2003
X-UIDL: 3e5baf6500000465
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34DNTGa010374;
	Fri, 4 Apr 2003 15:23:29 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h34DQKF13073;
	Fri, 4 Apr 2003 15:26:21 +0200 (MEST)
Message-ID: <3E8D8753.40905@eso.org>
Date: Fri, 04 Apr 2003 15:23:31 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: ael@star.le.ac.uk
CC: dal@ivoa.net
Subject: Re: IVOA WG data access layer
References: <00a601c2faa0$961cb3d0$cc24d28f@brolga>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

It was mentioned before, but conceptually VOQL appears to be closer to 
an extension of an SQL-kind of query language whereas DAL will deal with 
things like

- how to turn info harvested from a registry into a VOQL query
- how to perform transaction management of distributed queries
- error handling
- ?

Consequently, if VOQL returns tabular data then DAL has to have a method 
to transfer it to a scratch space where the results from other sub 
queries are assembled.

Markus


Tony Linde wrote:
> I think the DAL has to look at all types of access to data whether querying
> catalogues, accessing images, time series or spectra and any other type of
> data access.
> 
> Or is the split intended to be: 
> 
> . VOQL addresses access to tabular data
> 
> . DAL addresses access to non-tabular data
> 
> Might work.
> 
> Cheers,
> Tony. 

From - Fri Apr  4 17:06:58 2003
X-UIDL: 3e5baf650000046d
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <borne@rings.gsfc.nasa.gov>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34F6JGa000319
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 17:06:19 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34F6Je15173
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 17:06:19 +0200 (MEST)
Received: from rings.gsfc.nasa.gov(128.183.190.139) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAOuaGOD; Fri, 4 Apr 03 17:06:17 +0200
Received: (from borne@localhost)
	by rings.gsfc.nasa.gov (8.9.3p2/8.9.3) id KAA03376;
	Fri, 4 Apr 2003 10:02:26 -0500 (EST)
From: Kirk Borne <borne@rings.gsfc.nasa.gov>
Message-Id: <200304041502.KAA03376@rings.gsfc.nasa.gov>
Subject: Re: IVOA WG data access layer
To: cgp@star.le.ac.uk (Clive Page)
Date: Fri, 4 Apr 2003 10:02:26 -0500 (EST)
Cc: Markus.Dolensky@eso.org (Markus Dolensky), dal@ivoa.net,
   ktn@star.le.ac.uk (Keith Noddle)
In-Reply-To: <Pine.LNX.4.44L0.0304041226270.7530-100000@peneca.star.le.ac.uk> from "Clive Page" at Apr 04, 2003 12:28:29 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Hi.  the VOQL developments in the US NVO project are being discussed
this morning at the NVO Project Team Meeting at Caltech.  You will
probably here more soon.

- Kirk Borne

> From mdolensk@eso.org Fri Apr  4 06:41 EST 2003
> Date: Fri, 4 Apr 2003 12:28:29 +0100 (BST)
> From: Clive Page <cgp@star.le.ac.uk>
> To: Markus Dolensky <Markus.Dolensky@eso.org>
> cc: dal@ivoa.net, Keith Noddle <ktn@star.le.ac.uk>
> Subject: Re: IVOA WG data access layer
> 
> On Fri, 4 Apr 2003, Markus Dolensky wrote:
> 
> > The actual query could be based on a TBD VOQL for which there is another
> > WG.
> 
> Yes, but the VOQL working group appears not yet to have got off the
> ground, and the mailing list (to which I subscribe) has had very little
> traffic.  Since these topics are quite closely related, it is hard to know
> whether to deal with them separately or together.
> 
> -- 
> Clive Page,
> Dept of Physics & Astronomy,
> University of Leicester,    Tel +44 116 252 3551
> Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311

From - Fri Apr  4 18:51:59 2003
X-UIDL: 3e5baf6500000472
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34GlTGa015678
	for <dal@ivoa.net>; Fri, 4 Apr 2003 18:47:30 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34GlTP20776
	for <dal@ivoa.net>; Fri, 4 Apr 2003 18:47:29 +0200 (MEST)
Received: from rain.ipac.caltech.edu(134.4.10.130) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAFAa4KO; Fri, 4 Apr 03 18:47:28 +0200
Received: from rain.ipac.caltech.edu (localhost [127.0.0.1])
	by rain.ipac.caltech.edu (8.11.7/8.11.6) with ESMTP id h34GduZ13780
	for <dal@ivoa.net>; Fri, 4 Apr 2003 08:39:56 -0800 (PST)
Received: from ipac.caltech.edu (net-serve2.ipac.caltech.edu [134.4.40.46])
	by rain.ipac.caltech.edu (8.11.7/8.11.6) with ESMTP id h34Gdpp13759;
	Fri, 4 Apr 2003 08:39:51 -0800 (PST)
Message-ID: <3E8DB58A.DFD601FE@ipac.caltech.edu>
Date: Fri, 04 Apr 2003 08:40:43 -0800
From: John Good <jcg@ipac.caltech.edu>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: ja,zh-TW,zh,zh-CN
MIME-Version: 1.0
To: Arnold Rots <arots@head-cfa.cfa.harvard.edu>
CC: Roy Williams <roy@cacr.caltech.edu>, Doug Tody <dtody@nrao.edu>,
   Steve Lowe <slowe@cfa.harvard.edu>, metadata <metadata@us-vo.org>,
   dal@ivoa.net
Subject: Re: Call for proposals for SIAP Version 2
References: <200304040018.h340I2207647@xebec.cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   



Arnold -

> Though I in general agree with this, the comments below are too
> restrictive.  A convex polygon may be sufficient for queries, but
> certainly not for general applications.  And one has to be careful
> when dealing with projections.  Great circles are straight lines in
> TAN projections, but not in any other.  Concave polygons and regions
> with holes will need to be dealt with.

I agree that complex regions will have to be dealt with in general.
However, convex polygons are so simple to deal with and cover
such a large fraction of the query instances that we are likely to
encounter that I think it would be short-sighted not to include
them in the baseline request syntax (both for image access and for
catalogs).

Besides, a general complex region to a service that does not have
that ability to provide complex filtering would benefit from that
service at least being able to return the data from a bounding
polygon, which is easy to create from the complex region definition.

While it is true that TAN is the only projection where image corners
are precisely connected by straight lines,  many real-world images
cover small enough regions of the sky to make the polygon approximation
good enough for almost any projection (SIN, STG, etc.)  I'll think you'll
find that for most of the images coming out of archives, we're talking
about a fraction of a pixel maximum deviation from the a great circle.

Also, for most common projection, the great circle connected area
contains the true area, so queries return a few more candidates than
an exact filter would produce, which can then be filtered.

- John

From - Fri Apr  4 19:01:58 2003
X-UIDL: 3e5baf6500000473
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34H0mGa020893
	for <dal@ivoa.net>; Fri, 4 Apr 2003 19:00:48 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34H0m321263
	for <dal@ivoa.net>; Fri, 4 Apr 2003 19:00:48 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAeEaqHP; Fri, 4 Apr 03 19:00:47 +0200
Received: from cfa.harvard.edu (pioneer [131.142.184.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h34GrDid000981;
	Fri, 4 Apr 2003 11:53:13 -0500 (EST)
Message-ID: <3E8DB879.1060406@cfa.harvard.edu>
Date: Fri, 04 Apr 2003 11:53:13 -0500
From: Steve Lowe <slowe@cfa.harvard.edu>
Organization: SAO / CfA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Good <jcg@ipac.caltech.edu>
CC: Roy Williams <roy@cacr.caltech.edu>, Doug Tody <dtody@nrao.edu>,
   metadata
 <metadata@us-vo.org>, dal@ivoa.net
Subject: Re: Call for proposals for SIAP Version 2
References: <Pine.LNX.4.44.0304020833240.10904-100000@localhost.localdomain> <06ce01c2f93f$b5889c00$6b91d783@cacr.caltech.edu> <3E8B3450.62B2C6F7@ipac.caltech.edu> <3E8C4D4C.7070506@cfa.harvard.edu> <3E8CBF98.595E3B6F@ipac.caltech.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Hi John,

Perhaps we are not so much in disagreement. In our group we started out 
just wanting to be able to ask for a data product that looked like a 
spectrum, that is, something with data values (fluxes) measured at a 
range values of frequency/wavelength, just as an image has flux measured 
at a range of spatial positions. That parallel suggested that the Region 
of Interest should be able to indicate a frequency band in addition to 
sky position; indeed, this capability would be useful for traditional 
images, for example to request only, say, radio images. We didn't want 
to just patch in spectra, so we thought about how the query might 
indicate the physical properties it was interested in, the ranges of 
values for those quantities that are of interest, and the types of data 
the client wants to get back. It is anticipated that other disciplines 
might propose adding additional properties, such as time or polarization 
state, so we sought a somewhat extensible framework. In this framework 
the client has to indicate which physical concepts appear in the query, 
and so allowing coordinate systems to be specified as well seemed a 
natural extension, especially for a field like spectroscopy for which 
the sub-disciplines strongly favor different systems (frequency, 
wavelength, energy).

So that's my recollection of how coordinate systems got into the act. I 
favor providing the mechanism for client/service negotiation on 
coordinate systems, even if most "good" services accept everything.

But the main point, I think, is to expand the types of measurements that 
can be queried.

Steve

John Good wrote:

>Steve -
>
>  
>
>>Coordinate transforms are not difficult, but they're not trivial to get
>>right either. This is especially so if we depart from the "distant" sky
>>and try to specify more local observations for which the observing
>>position is important.
>>
>>While I generally agree with the philosophy of providing know-how rather
>>than software, I think realistically it will be beneficial to keep the
>>buy-in cost low as Roy suggests. Consider that the user receives the
>>direct benefit in acquiring data from a provider. The provider's
>>benefit, if any, may be more indirect, such as community publicity or
>>favor of the funding agencies. This is an argument for making life as
>>easy as possible for the provider.
>>
>>I don't think portable code snippets will do, I think you'd need a
>>supported software library.
>>    
>>
>
>I agree and there are at least a couple of coordinate transform libraries
>already.  The code snippets I was referring to would be examples of
>how to do the polygon, etc. constraint filtering.
>
>
>  
>
>>Whatever the ultimate decision on whether clients or providers have to
>>support multiple coordinate systems, for now this capability can be used
>>as a model to examine client-provider negotiation.
>>    
>>
>
>Since providers can be readily taught how to provide more complete
>spatial filtering, I think this is the wrong place to experiment on
>negotiation (at least until we get to more complex regions).
>
>I would say a more relevant area for negotiation would be related
>to query engine capabilities, particularly regarding the ability to place
>additional relational constraints on metadata that passes the
>positional filter.
>
>For instance, our "Cone Search" service already allows for the full
>range of positional constraints I described (and which I think can be
>implemented universally).  It also allows for generic SQL constraints
>("WHERE" clauses) on any of the fields in the table.  Now, for those
>implementations which are not build on top of DBMS technology,
>I can see that this ability could be difficult.  They might have no
>such filtering or might only be able to filter on something like magnitude
>ranges for a specific field.
>
>I would like to see this ability called out as a part of both a more general
>catalog search (superceding the Cone Search) and as an extension of the
>SIA protocol.  Here there is  definitely a need for client-provider
>negotiation, not just on whether this capability exists but then on the
>"data dictionary" associated  with the fields that can be constrained
>(or "SELECT"ed for that matter).
>
>We provide the data dictionary information as a separate XML
>service but it be envisioned as part of the same protocol suite.
>
>- John
>
>
>  
>


-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe@cfa.harvard.edu
1-617-496-1661



From - Fri Apr  4 20:11:58 2003
X-UIDL: 3e5baf6500000478
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <dtody@nrao.edu>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34I8SGa018353
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 20:08:28 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34I8Sc24363
	for <Markus.Dolensky@eso.org>; Fri, 4 Apr 2003 20:08:28 +0200 (MEST)
Received: from cv3.cv.nrao.edu(192.33.115.2) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcCAADvaWJV; Fri, 4 Apr 03 20:08:27 +0200
Received: from polaris.cv.nrao.edu (polaris.cv.nrao.edu [192.33.115.101])
	by cv3.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h34I5Cj18957;
	Fri, 4 Apr 2003 13:05:12 -0500
Received: from oak (oak.aoc.nrao.edu [146.88.1.137])
	by polaris.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h34I5Bs26496;
	Fri, 4 Apr 2003 13:05:11 -0500
Date: Fri, 4 Apr 2003 11:05:10 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: Clive Page <cgp@star.le.ac.uk>
cc: Markus Dolensky <Markus.Dolensky@eso.org>, <dal@ivoa.net>,
   Keith Noddle <ktn@star.le.ac.uk>
Subject: Re: IVOA WG data access layer
In-Reply-To: <Pine.LNX.4.44L0.0304041226270.7530-100000@peneca.star.le.ac.uk>
Message-ID: <Pine.LNX.4.44.0304041101050.12878-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.2, required 7,
	EMAIL_ATTRIBUTION, IN_REP_TO, SPAM_PHRASE_00_01, USER_AGENT_PINE)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Ultimately we should have some standardization of queries across the
data access services.  VOQL promises to address this problem, but I think
it will be a while before there is anything we can use and we will need
to continue to integrate a simplified query capability into the services
for some time.  We might be able to make some progress in the areas of
service metadata (to identify the query attributes to a client), and in
query elements such as POS,SIZE, region specifications, and so forth
(i.e. the elements of an astronomical query, which might be later folded
into some more powerful query syntax.).   Doug



On Fri, 4 Apr 2003, Clive Page wrote:

> On Fri, 4 Apr 2003, Markus Dolensky wrote:
> 
> > The actual query could be based on a TBD VOQL for which there is another
> > WG.
> 
> Yes, but the VOQL working group appears not yet to have got off the
> ground, and the mailing list (to which I subscribe) has had very little
> traffic.  Since these topics are quite closely related, it is hard to know
> whether to deal with them separately or together.
> 
> 

From - Fri Apr  4 20:56:58 2003
X-UIDL: 3e5baf650000047a
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34ItQGa012256
	for <dal@ivoa.net>; Fri, 4 Apr 2003 20:55:27 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34ItQ826205
	for <dal@ivoa.net>; Fri, 4 Apr 2003 20:55:26 +0200 (MEST)
Received: from rain.ipac.caltech.edu(134.4.10.130) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAfJa4kZ; Fri, 4 Apr 03 20:55:24 +0200
Received: from rain.ipac.caltech.edu (localhost [127.0.0.1])
	by rain.ipac.caltech.edu (8.11.7/8.11.6) with ESMTP id h34IlrZ03161
	for <dal@ivoa.net>; Fri, 4 Apr 2003 10:47:53 -0800 (PST)
Received: from ipac.caltech.edu (oasis.ipacds.ipac.caltech.edu [134.4.70.173])
	by rain.ipac.caltech.edu (8.11.7/8.11.6) with ESMTP id h34Ilnp03144;
	Fri, 4 Apr 2003 10:47:49 -0800 (PST)
Message-ID: <3E8DD355.31B37F06@ipac.caltech.edu>
Date: Fri, 04 Apr 2003 10:47:49 -0800
From: John Good <jcg@ipac.caltech.edu>
Organization: IPAC / Caltech
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Lowe <slowe@cfa.harvard.edu>
CC: Roy Williams <roy@cacr.caltech.edu>, Doug Tody <dtody@nrao.edu>,
   metadata <metadata@us-vo.org>, dal@ivoa.net
Subject: Re: Call for proposals for SIAP Version 2
References: <Pine.LNX.4.44.0304020833240.10904-100000@localhost.localdomain> <06ce01c2f93f$b5889c00$6b91d783@cacr.caltech.edu> <3E8B3450.62B2C6F7@ipac.caltech.edu> <3E8C4D4C.7070506@cfa.harvard.edu> <3E8CBF98.595E3B6F@ipac.caltech.edu> <3E8DB879.1060406@cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   



Steve -

> Perhaps we are not so much in disagreement. In our group we started out
> just wanting to be able to ask for a data product that looked like a
> spectrum, that is, something with data values (fluxes) measured at a
> range values of frequency/wavelength, just as an image has flux measured
> at a range of spatial positions.

While this might belong in the same "family" of services, I think it
muddies the waters to try and fold it and the SIA together operationally.
A positional constraint on the sky, whether for SIA or a Catalog Search
replacement for the Cone Search, is pretty fundemental and (in various
forms) already used extensively.  I think it makes more sense to keep
it separate from frequency/wavelength/etc. issues.


>                                             That parallel suggested that the
> Region
> of Interest should be able to indicate a frequency band in addition to
> sky position; indeed, this capability would be useful for traditional
> images, for example to request only, say, radio images. We didn't want
> to just patch in spectra, so we thought about how the query might
> indicate the physical properties it was interested in, the ranges of
> values for those quantities that are of interest, and the types of data
> the client wants to get back. It is anticipated that other disciplines
> might propose adding additional properties, such as time or polarization
> state, so we sought a somewhat extensible framework. In this framework
> the client has to indicate which physical concepts appear in the query,
> and so allowing coordinate systems to be specified as well seemed a
> natural extension, especially for a field like spectroscopy for which
> the sub-disciplines strongly favor different systems (frequency,
> wavelength, energy).

The "axes" in parameter space exist in pretty  orthogonal groups
(sky coordinates, photometry/polarization, temporal, etc.), so while
I agree that a common approach to setting constraints makes sense,
I don't see too much to be gained by trying to shoehorn everything into
a single query clause or even detailed syntax.


> So that's my recollection of how coordinate systems got into the act. I
> favor providing the mechanism for client/service negotiation on
> coordinate systems, even if most "good" services accept everything.
>
> But the main point, I think, is to expand the types of measurements that
> can be queried.

Sky coordinates, because they are two dimensional on a sphere, have to be
queried differently from typical relational constraints.  In our services,
everything else is handled by simply allowing fragments of SQL syntax
(e.g. "date between 10 and 20 or J_magnitude < 8.").  I can *imagine* needing
more complex constructs in other subspaces but we've never encountered
that need in practice.  Do you have instances of specific constraints that
don't work with fairly the simple SQL WHERE-clause construct?

- John

From - Sat Apr  5 00:11:59 2003
X-UIDL: 3e5baf6500000480
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h34MA9iK016173
	for <dal@ivoa.net>; Sat, 5 Apr 2003 00:10:09 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h34MA9J04369
	for <dal@ivoa.net>; Sat, 5 Apr 2003 00:10:09 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAe6aaIi; Sat, 5 Apr 03 00:10:08 +0200
Received: from cfa.harvard.edu (pioneer [131.142.184.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h34M2Yid016751;
	Fri, 4 Apr 2003 17:02:34 -0500 (EST)
Message-ID: <3E8E00FA.5010403@cfa.harvard.edu>
Date: Fri, 04 Apr 2003 17:02:34 -0500
From: Steve Lowe <slowe@cfa.harvard.edu>
Organization: SAO / CfA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: John Good <jcg@ipac.caltech.edu>
CC: Roy Williams <roy@cacr.caltech.edu>, Doug Tody <dtody@nrao.edu>,
   metadata
 <metadata@us-vo.org>, dal@ivoa.net
Subject: Re: Call for proposals for SIAP Version 2
References: <Pine.LNX.4.44.0304020833240.10904-100000@localhost.localdomain> <06ce01c2f93f$b5889c00$6b91d783@cacr.caltech.edu> <3E8B3450.62B2C6F7@ipac.caltech.edu> <3E8C4D4C.7070506@cfa.harvard.edu> <3E8CBF98.595E3B6F@ipac.caltech.edu> <3E8DB879.1060406@cfa.harvard.edu> <3E8DD355.31B37F06@ipac.caltech.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

John Good wrote:

>While this might belong in the same "family" of services, I think it
>muddies the waters to try and fold it and the SIA together operationally.
>A positional constraint on the sky, whether for SIA or a Catalog Search
>replacement for the Cone Search, is pretty fundemental and (in various
>forms) already used extensively.  I think it makes more sense to keep
>it separate from frequency/wavelength/etc. issues.
>  
>
Do positional and wavelength constraints just seem different because of 
the way data is currently organized? Since an archive is often 
associated with a single instrument or collection of similar 
instruments, wavelength is already somewhat narrowed down just by the 
choice of archive, so sky position becomes the dominant search 
constraint *within* an archive. But if you're thinking of posing a query 
to the union of all archives, mightn't a wavelength constraint make as 
much sense as a positional constraint? Suppose you want to assemble a 
whole sky survey in a particular frequency band?

>Sky coordinates, because they are two dimensional on a sphere, have to be
>queried differently from typical relational constraints.  In our services,
>everything else is handled by simply allowing fragments of SQL syntax
>(e.g. "date between 10 and 20 or J_magnitude < 8.").  I can *imagine* needing
>more complex constructs in other subspaces but we've never encountered
>that need in practice.  Do you have instances of specific constraints that
>don't work with fairly the simple SQL WHERE-clause construct?
>
I'll have to think about this a little more, but I'm not sure we're 
proposing anything more complicated than WHERE. We're just including 
units and coordinate systems in the WHERE.

Steve

-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe@cfa.harvard.edu
1-617-496-1661



From - Thu Apr 10 14:03:39 2003
X-UIDL: 3e5baf650000052f
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3ABx6hl003319;
	Thu, 10 Apr 2003 13:59:06 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3ABx6B13229;
	Thu, 10 Apr 2003 13:59:06 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAcEaG1z; Thu, 10 Apr 03 13:59:05 +0200
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h3ABvnWI016241
          ; Thu, 10 Apr 2003 13:57:49 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id NAA01206;
	Thu, 10 Apr 2003 13:50:23 +0200 (MET DST)
Date: Thu, 10 Apr 2003 13:50:23 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200304101150.NAA01206@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: cambridge meeting
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h3ABvnWI016241
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h3ABxxhl003530
Status:   

Hello ,
   just to say: I agree with the current agenda 
  for working group meetings specialy because it
   seems to be comatible to go both to Data Model
   and DAL sessions on Tuesday
   Any new agenda should allow that, I hope.
Regards
François


=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From - Sat Apr 12 01:45:26 2003
X-UIDL: 3e5baf6500000561
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3BNfe2T022399;
	Sat, 12 Apr 2003 01:41:41 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3BNfeO09572;
	Sat, 12 Apr 2003 01:41:40 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAi5aqSs; Sat, 12 Apr 03 01:41:39 +0200
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h3BNeOWI054883
          ; Sat, 12 Apr 2003 01:40:24 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id BAA27866;
	Sat, 12 Apr 2003 01:32:56 +0200 (MET DST)
Date: Sat, 12 Apr 2003 01:32:56 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200304112332.BAA27866@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: AVO prototype metadata tree
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h3BNeOWI054883
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h3BNfp2T022421
Status:   

Hello,
   I just send in my next mail a first version of the
documentation on the AVO prototype metadata tree developped
at CDS for the january demo, and which we are currently
customizing for more general use. An annotated example will
come in a week or so. The protocol described here is to
some very small exceptions the one accessible at 
http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?out=qualifier
&position=053.11629+-27.80875&radius=0.25&mode=xml_votable_idha
Regards
François Bonnarel

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From - Mon Apr 14 12:12:43 2003
X-UIDL: 3e5baf6500000577
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3EAB8aG016431;
	Mon, 14 Apr 2003 12:11:08 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h3EAEDF04099;
	Mon, 14 Apr 2003 12:14:13 +0200 (MEST)
Message-ID: <3E9A8943.7020308@eso.org>
Date: Mon, 14 Apr 2003 12:11:15 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
CC: dal@ivoa.net, dm@ivoa.net
Subject: =?ISO-8859-1?Q?Re=3A_Metadata_tree_Some_documentation_?=
 =?ISO-8859-1?Q?for_a_metadata-tree_=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D?=
 =?ISO-8859-1?Q?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D?=
 =?ISO-8859-1?Q?=3D=3D=3D=3D=3D=3D=3D=3D_Mark_Allen_and_Fran=E7oi?=
 =?ISO-8859-1?Q?s_Bonnarel_Version_0=2E0?=
References: <200304112337.BAA27886@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Dear Francois,

thank you for the documentation of the metadata browser. If I interpret 
the subject line correctly it is also Mark's work.

 > The meaning of all the attributes will be clarified by an
 > annotated example, which will be available soon.

The AVO prototype has got two trees: One for images, one for catalogs.
Will you also give an example on how to include a selection of catalogs?

Cheers,
Markus

+---
| Markus Dolensky   Mailto:Markus.Dolensky@eso.org
| AVO Technical Lead          Web: www.euro-vo.org
| Voice: ++49 89 32006/261  Fax: ++49 89 32006/480
+---



From - Mon Apr 14 12:50:30 2003
X-UIDL: 3e5baf6500000578
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <bonnarel@alinda.u-strasbg.fr>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3EAjTaG003689
	for <Markus.Dolensky@eso.org>; Mon, 14 Apr 2003 12:45:29 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3EAjTF16500
	for <Markus.Dolensky@eso.org>; Mon, 14 Apr 2003 12:45:29 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAnnayoG; Mon, 14 Apr 03 12:45:28 +0200
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h3EAiCWI035900
          ; Mon, 14 Apr 2003 12:44:12 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id MAA15022;
	Mon, 14 Apr 2003 12:36:43 +0200 (MET DST)
Date: Mon, 14 Apr 2003 12:36:43 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200304141036.MAA15022@alinda.u-strasbg.fr>
To: Markus.Dolensky@eso.org
Subject: Re: =?ISO-8859-1?Q?Re=3A_Metadata_tree_Some_documentation_?= =?ISO-8859-1?Q?for_a_metadata-tree_=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D?= =?ISO-8859-1?Q?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D?= =?ISO-8859-1?Q?=3D=3D=3D=3D=3D=3D=3D=3D_Mark_Allen_and_Fran=E7oi?= =?ISO-8859-1?Q?s_Bonnarel_Version_0=2E0?=
Cc: dal@ivoa.net, dm@ivoa.net
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h3EAiCWI035900
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h3EAjTaG003689
Status:   

Dear Markus,

   Yes it is a common work by Mark Allen and me. 

   The catalogue part of the tree was not intended to be part of the
annotated exemple, but we can think to it ....

Regards
François:wq

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From - Sat Apr 12 01:45:26 2003
X-UIDL: 3e5baf6500000562
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3BNiX2T023387;
	Sat, 12 Apr 2003 01:44:33 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3BNiXW09654;
	Sat, 12 Apr 2003 01:44:33 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAQaai2s; Sat, 12 Apr 03 01:44:32 +0200
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h3BNiVWI056779
          ; Sat, 12 Apr 2003 01:44:31 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id BAA27886;
	Sat, 12 Apr 2003 01:37:04 +0200 (MET DST)
Date: Sat, 12 Apr 2003 01:37:04 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200304112337.BAA27886@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: Metadata tree Some documentation for a metadata-tree ====================================== Mark Allen and François Bonnarel Version 0.0
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Introduction
============
Browsing and visualization of image datasets will be an
important part of Virtual Observatory operations. Such
datasets may range from a small set of images stored on
a local disk, to the terabyte collections of modern
surveys made accessible via various Web Services. Standardized
and scalable descriptions of image metadata will be required to
enable dataset browsing, selection and visualization.

The Metadata Tree that was developed for the AVO 1st year
demonstration represents a prototype implementation of a
scalable, hierarchical metadata description (in VOTABLE/XML)
of an image dataset. This component of the AVO prototype was built as
a customization of the Load feature of the Aladin sky atlas,
and was designed specifically for the GOODS dataset. Using a
VOTABLE description, it displays a tree view of the data available
within a specified region (or range of parameters), allows display
of fields-of-view outlines, and provides feedback between the tree
and visualization window. The metadata description includes the
location and retrieval parameters for the data, in the case of
GOODS this was basically a http-get template for the GOODS data server
at the CDS.

Following user feedback on the Metadata Tree component of the
AVO prototype it was decided to implement a generalized Metadata
Tree function in the public version of the Aladin sky atlas
(version 1.5 ?). This allows description of other datasets (local or
remote) in the same way as was done for the GOODS dataset, so
that they have similar functionality within Aladin.

This document outlines how to define a VOTABLE description
of a dataset for use with Aladin.


Relationship to the IDHA Data Model
===================================
The metadata description of the GOODS data used for the AVO
demo was based on a generic description of astronomical data
being developed by the IDHA data model project. The goal of the
IDHA data model project is to describe the information content
of image archives and datasets. In the IDHA data model the
metadata are coded as objects, with logical links between them.
The graph of the IDHA data model is shown at 
http://alinda.u-strasbg.fr/IDHA/lastmodel.

While the use of the data model is not required to generate
the VOTABLE for a general dataset, it is instructive to see how
the general form of the VOTABLE description relates to the data
model graph. Various tree structures may be extracted from the model
graph. In general this is done by starting at a node, and following
various links, avoiding reverse and circular links. In the case of
GOODS, the tree was chosen with a hierarchy organized in terms of:

ObservingProgram - ObservingGroups - ProcessedObservations

This can be described as one "view of the data model",
but it is also possible to use the model to define trees with
different hierarchies, and different starting points. For example
by starting from ProcessedObservation one may generate a tree
that has branches describing the instrument used, and the observing 
conditions etc.


VOTABLE description of a dataset
================================

Here we describe in detail how to structure a VOTABLE description
of a dataset for use with the Aladin Metadata Tree. VOTABLE has the
capability of describing not only flat table structures, but can also
describe a hierarchical tree. The Metadata Tree is expressed in VOTABLE by
recursive use of the <RESOURCE> element. Each <RESOURCE>
element represents a node of the tree. The children of the nodes appear
as new <RESOURCE> elements included in the previous one.

NODES
-----------
In this description we make use of three different kinds of nodes:
"ObservingProgram", "ObservationGroup", and "ProcessedObservation".
These relate to parts of the data model with the same name.

"ObservingProgram" nodes are intended to be the root nodes. Several root
nodes may occur in a single document.

"ObservationGroup" nodes are the children of "ObservingProgram" nodes,
or other "ObservationGroup" nodes. These nodes are intended to be the
main way of subsetting the dataset into a hierarchy.

"ProcessedObservation" nodes are children of the "ObservationGroup"
nodes and are intended to contain the description of a subset of the
image metadata that will be useful to display, for example field
centre coordinates and sizes. This is intended for information relevant
to an Astronomer.

"StorageMapping" nodes are linked to the "ProcessedObservation". They are
intended to contain detailed metadata about the images that are required
for using the images in an interface.


NODE ATTRIBUTES
-------------------------------

The attributes of a node are defined within the <TABLE> part of the
<RESOURCE> element.  Each attribute of the model class is
coded as a <FIELD> in the <RESOURCE>.
The use of these attributes is necessary to enable the full functionality
of the Metadata Tree within Aladin. The tree will however minimally
function provided the main node definitions are included.
We now provide a list of the attributes we are using, and define them
as recommended or optional.
  
For ObservingProgram, the <FIELDS> or attributes are:

* Name (recommended),     the ObservingProgram Name.
* Organisation(optional), the Name of Organisation(s) performing Observing Program
* Begin(optional),        the Begin date of the survey
* End(optional),          the End date of Observing program
* SpectralDomain(recommended), the General spectral domain (Optical X-ray ...)

For Observation_group, the <FIELDS> or attributes we have are:

* Selection_Criterion(recommended), for the Sampled parameter.
  A sampled parameter can be any attribute of any class of the data model
  considered useful. For example: Filter name (or filter range), 
  epoch of observation, Polarizer state, etc ...
* Selection-Range(recommended) , the Constraint on the sampled parameter

For Processed Observation, the <FIELDS> or attributes we have are:

* Observation_Name(recommended) , the name of the Observation
* ReferenceNumber (optional), an internal or reference number of the Observation
* Size_alpha (recommended), the Bounding box size including the observation 
                            in Right Ascension
* Size_delta (recommended), the Bounding box size including the observation 
                            in Declination
* PixelSize (recommended),  the Pixel size measured in sky units.Actual unit
                            (arsec,arcmin,deg)is given in the FIELD definition.
* Origin (optionnal),       the Organism who provided the data.
* OriginalCoding (optional), the image format provided 
* AvailableCodings (optional), for the possible codings of these data in request
* alpha(recommended),         the RA Position of center
* delta(recommended),         the DEC Position of center
* Position Angle,          the Position Angle of the Observation Y axis East of 
                              North

The meaning of all the attributes will be clarified by an
annotated example, which will be available soon.


DATA LOCATION
----------------------------------------------------

The data location parameters are set within the StorageMapping 
<RESOURCE> element. The attribute (<FIELD>) is Location, 
the value of which can be a file path, an URL or a GLU mark. 
The file path is intended for referring to local files only.
Each file path must be preceded by  "file:"
URL and Glu Marks are intended to provide access to remote files. 
Glu marks are prececed by "glu:" The Glu marks allow for inclusion
of parametrized URL templates. To enable this facility the service 
needs to be registered in a GLU database.



 




=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From - Fri Apr 18 01:45:20 2003
X-UIDL: 3e5baf650000060b
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3HNhOHO010777;
	Fri, 18 Apr 2003 01:43:24 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3HNhOV21360;
	Fri, 18 Apr 2003 01:43:24 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAgMa4TP; Fri, 18 Apr 03 01:43:23 +0200
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h3HNg7WI006129
          ; Fri, 18 Apr 2003 01:42:07 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id BAA07356;
	Fri, 18 Apr 2003 01:34:34 +0200 (MET DST)
Date: Fri, 18 Apr 2003 01:34:34 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200304172334.BAA07356@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: metadata tree with annotated exemple
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h3HNg7WI006129
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h3HNhlHO010784
Status:   

                  Metadata tree Some documentation for a metadata-tree 
                         ====================================== 
                  Mark Allen and François Bonnarel Version 0.1

Introduction
============
Browsing and visualization of image datasets will be an
important part of Virtual Observatory operations. Such
datasets may range from a small set of images stored on
a local disk, to the terabyte collections of modern
surveys made accessible via various Web Services. Standardized
and scalable descriptions of image metadata will be required to
enable dataset browsing, selection and visualization.

The Metadata Tree that was developed for the AVO 1st year
demonstration represents a prototype implementation of a
scalable, hierarchical metadata description (in VOTABLE/XML)
of an image dataset. This component of the AVO prototype was built as
a customization of the Load feature of the Aladin sky atlas,
and was designed specifically for the GOODS dataset. Using a
VOTABLE description, it displays a tree view of the data available
within a specified region (or range of parameters), allows display
of fields-of-view outlines, and provides feedback between the tree
and visualization window. The metadata description includes the
location and retrieval parameters for the data, in the case of
GOODS this was basically a http-get template for the GOODS data server
at the CDS.

Following user feedback on the Metadata Tree component of the
AVO prototype it was decided to implement a generalized Metadata
Tree function in the public version of the Aladin sky atlas
(version 1.5 ?). This allows description of other datasets (local or
remote) in the same way as was done for the GOODS dataset, so
that they have similar functionality within Aladin.

This document outlines how to define a VOTABLE description
of a dataset for use with Aladin.


Relationship to the IDHA Data Model
===================================
The metadata description of the GOODS data used for the AVO
demo was based on a generic description of astronomical data
being developed by the IDHA data model project. The goal of the
IDHA data model project is to describe the information content
of image archives and datasets. In the IDHA data model the
metadata are coded as objects, with logical links between them.
The graph of the IDHA data model is shown at 
http://alinda.u-strasbg.fr/IDHA/lastmodel.

While the use of the data model is not required to generate
the VOTABLE for a general dataset, it is instructive to see how
the general form of the VOTABLE description relates to the data
model graph. Various tree structures may be extracted from the model
graph. In general this is done by starting at a node, and following
various links, avoiding reverse and circular links. In the case of
GOODS, the tree was chosen with a hierarchy organized in terms of:

ObservingProgram - ObservingGroups - ProcessedObservations

This can be described as one "view of the data model",
but it is also possible to use the model to define trees with
different hierarchies, and different starting points. For example
by starting from ProcessedObservation one may generate a tree
that has branches describing the instrument used, and the observing 
conditions etc.


VOTABLE description of a dataset
================================

Here we describe in detail how to structure a VOTABLE description
of a dataset for use with the Aladin Metadata Tree. VOTABLE has the
capability of describing not only flat table structures, but can also
describe a hierarchical tree. The Metadata Tree is expressed in VOTABLE by
recursive use of the <RESOURCE> element. Each <RESOURCE>
element represents a node of the tree. The children of the nodes appear
as new <RESOURCE> elements included in the previous one.

NODES
-----------
In this description we make use of three different kinds of nodes:
"ObservingProgram", "Observation_Group", and "ProcessedObservation".
These relate to parts of the data model with the same name.

"ObservingProgram" nodes are intended to be the root nodes. Several root
nodes may occur in a single document.

"Observation_Group" nodes are the children of "ObservingProgram" nodes,
or other "Observation_Group" nodes. These nodes are intended to be the
main way of subsetting the dataset into a hierarchy.

"ProcessedObservation" nodes are children of the "Observation_Group"
nodes and are intended to contain the description of a subset of the
image metadata that will be useful to display, for example field
centre coordinates and sizes. This is intended for information relevant
to an Astronomer.

"StorageMapping" nodes are linked to the "ProcessedObservation". They are
intended to contain detailed metadata about the images that are required
for using the images in an interface.


NODE ATTRIBUTES
-------------------------------

The attributes of a node are defined within the <TABLE> part of the
<RESOURCE> element.  Each attribute of the model class is
coded as a <FIELD> in the <RESOURCE>.
The use of these attributes is necessary to enable the full functionality
of the Metadata Tree within Aladin. The tree will however minimally
function provided the main node definitions are included.
We now provide a list of the attributes we are using, and define them
as recommended or optional.
A tree with all the recommended attributes will be called an IDHA metadata tree 
(Image Data Hierarchical Access tree)
  
For ObservingProgram, the <FIELDS> or attributes are:

* Name (recommended),     the ObservingProgram name.
* Organisation(optional), the name of Organisation(s) performing Observing Program
* Begin(optional),        the Begin date of the survey
* End(optional),          the End date of Observing program
* SpectralDomain(recommended), the General spectral domain (Optical X-ray ...)

For Observation_Group, the <FIELDS> or attributes we have are:

* Selection_Criterion(recommended), for the Sampled parameter.
  A sampled parameter can be any attribute of any class of the data model
  considered useful. For example: Filter name (or filter range), 
  epoch of observation, Polarizer state, etc ...
* Selection-Range(recommended) , the Constraint on the sampled parameter
(Inside the Observation_Group resource we can find any resource describing
one aspect of the ObservingConfiguration on which the selection has been
made: in our annotated exemple, it is the case for the filter resource)

For Processed Observation, the <FIELDS> or attributes we have are:

* Observation_Name(recommended) , the name of the Observation
* ReferenceNumber (optional), an internal or reference number of the Observation
* Size_alpha (recommended), the Bounding box size including the observation 
                            in Right Ascension
* Size_delta (recommended), the Bounding box size including the observation 
                            in Declination
* PixelSize (recommended),  the Pixel size measured in sky units.Actual unit
                            (arsec,arcmin,deg)is given in the FIELD definition.
* Origin (optionnal),       the Organism who provided the data.
* OriginalCoding (optional), the image format provided 
* AvailableCodings (optional), for the possible codings of these data in request
* alpha(recommended),         the RA Position of center
* delta(recommended),         the DEC Position of center
* Position Angle,          the Position Angle of the Observation Y axis East of 
                              North

The meaning of all the attributes will be clarified by an
annotated example, which will be available soon.


DATA LOCATION
----------------------------------------------------

The data location parameters are set within the StorageMapping 
<RESOURCE> element. The attribute (<FIELD>) is Location, 
the value of which can be a file path, an URL or a GLU mark. 
The file path is intended for referring to local files only.
Each file path must be preceded by  "file:"
URL and Glu Marks are intended to provide access to remote files. 
Glu marks are prececed by "glu:" The Glu marks allow for inclusion
of parametrized URL templates. To enable this facility the service 
needs to be registered in a GLU database.



 


______________________________________________________________________
Annotated exemple

<?xml version="1.0"?>
<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">
<VOTABLE ID="v1.0">
 <DEFINITIONS>
 <COOSYS ID="J2000" system="eq_FK5" equinox="2000"/>
 </DEFINITIONS>
<!-- The info elements recall the request that we are answering...-->
 <INFO ID="position" value="53.116290 -27.808750"/>
 <INFO ID="radius" value="0.250000deg" />
 <INFO ID="type"  value="ObservingProgram,band,ProcessedObservation">
<!-- The ObservingProgram resource is the root node of our tree-->
<!-- Several Observing Programs resources can be appended in the same document...-->

 <RESOURCE name="ObservingProgram"  >
  <INFO ID="OPtype" value="survey"/>
  <!-- A resource has a table section which contains the specific attributes-->
  <!-- of the corresponding IDHA model object-->
  <TABLE ID="ObservingProgram">
    <DESCRIPTION>
      This is a few resource information for the
      ObservingProgram 
    </DESCRIPTION>
    <!-- Each field in this table is associated with an attribute of-->
    <!-- the model object  associated with the current resource "ObservingProgram"-->
    <FIELD ID="Name" name="Name" datatype="char" ucd="ID_SURVEY">
      <DESCRIPTION> ObservingProgram Name </DESCRIPTION>
    </FIELD>
    <FIELD ID="Organisation" name="Organisation" datatype="char" ucd="CURATOR">
      <DESCRIPTION> Name of Organisation(s) 
          performing Observing Program
      </DESCRIPTION>
    </FIELD>
    <FIELD ID="Begin" name="beginning_date" datatype="char">
     <DESCRIPTION> Begin date of the survey
     </DESCRIPTION>
    </FIELD>
    <FIELD ID="End" name="end date" datatype="char">
     <DESCRIPTION> End date of Observing program
     </DESCRIPTION>
    </FIELD>
    <FIELD ID="SpectralDomain" name="SpectralCoverageName" datatype="char">
     <DESCRIPTION> General spectral domain (Optical X-ray ...)
     </DESCRIPTION>
    </FIELD>
    <!-- The data elements can contain as many lines we have instances of the-->
    <!-- current class. However if the current instance has children in-->
    <!-- the tree: in that case we will only write one line, include the--> 
    <!-- children as new resources and then write later in the VOTABLE a -->
    <!-- new ressource with  the same name and another table-->
    <DATA><TABLEDATA>
      <TR><TD>GOODS-WFI</TD><TD>ESO</TD><TD>01/01/2002</TD><TD>31/12/2002</TD><TD>Optical</TD></TR>
    </TABLEDATA></DATA>
  </TABLE>
     <!-- We start a new resource (here Observation_Group) before closing the-->
     <!--  previous one.-->
     <RESOURCE name="Observation_Group" >
      <!-- The value attribute of the info element gives here the list-->
      <!-- of constrained attributes-->
     <INFO name ="OGtype" value="filter,epoch"/>
       <TABLE ID="Observation_Group">
        <DESCRIPTION> This is a subset of images 
          belonging to a survey, an experiment, 
          and organised according to the same 
          common criterion. e.g. exemple of 
          criterion: color or wavelength, 
          polarimetry, etc... exemple of 
          Observation_Group: POSSII band J, 
          DENIS band K, etc.. 
        </DESCRIPTION>
        
        <FIELD ID="Selection_Criterion" name="Selection_Criterion" datatype="char">
          <DESCRIPTION> Sampled Parameter
          </DESCRIPTION>
        </FIELD>
        <FIELD ID="Selection-Range" name="Selection-Range" datatype="char">
           <DESCRIPTION> Constraint on sampled parameter
           </DESCRIPTION>
        </FIELD>
        <!-- the first field gives the constrained parameter-->
        <!-- the second one is the constraint. a simple value-->
        <!-- like here is for a match to this value-->
        <!-- The observing group here is the conjonction of-->
        <!-- the filter and the epoch restrictions.-->
        <!-- It is possible to add other criteria as new lines in this table-->
        <!-- It is also possible to have criteria in another order-->
        <!-- Observation_Groups with the same constraint on the first -->
        <!-- criterium will be  grouped in the same node by the metadata tree-->
        <!-- browser.One can have as many levels of grouping in the Metadata -->
        <!-- tree than we have lines in the table -->
        <DATA><TABLEDATA>
          <TR><TD>"filter"</TD><TD>ICLWP</TD></TR>
          <TR><TD>"epoch"</TD><TD>epoch1</TD></TR>
        </TABLEDATA></DATA>
       </TABLE>
       <!-- The filter ressource included in the Observation_Group-->
       <!-- gives details on the Filter characteristics for the-->
       <!-- filter(s) used for the current band-->
         <RESOURCE name="Filter">
           <TABLE ID="Filter">
            <DESCRIPTION> 
                Description of the filter characteristics
            </DESCRIPTION>
            <FIELD ID="Minimal_wavelength" name="Minimal_wavelength" datatype="float" precision="F7" width="11" ucd="SPECT_WAVELENGTH" unit = "um">
              <DESCRIPTION> Minimal wavelength of the filter bandpath
              </DESCRIPTION>
            </FIELD>
            <FIELD ID="Maximal_wavelength" name="Maximal_wavelength" datatype="float" precision="F7" width="11" ucd="SPECT_WAVELENGTH" unit = "um">
               <DESCRIPTION> Maximal wavelength of the filter bandpath
               </DESCRIPTION>
            </FIELD>
            <FIELD ID="Effective_wavelength" name="Effective_wavelength" datatype="float" precision="F7" width="11" ucd="SPECT_WAVELENGTH " unit = "um">
               <DESCRIPTION> Effective wavelength of the filter bandpath
               </DESCRIPTION>
            </FIELD>
            <FIELD ID="Identifier" name="Identifier" datatype="char" ucd="ID_FILTER">
               <DESCRIPTION> Reference ID of the filter, according to the Instruments settings.
               </DESCRIPTION>
            </FIELD>
            <FIELD ID="Filter_Name" name="Filter_Name" datatype="char" ucd="ID_FILTER">
               <DESCRIPTION> Usual name of the band observed (ex: 2MASS K,SERC J,..)
               </DESCRIPTION>
            </FIELD>
            <DATA><TABLEDATA>
              <TR><TD>0.783000</TD><TD>1.001000</TD><TD></TD><TD>ICLWP</TD><TD></TD></TR>
            </TABLEDATA></DATA>
           </TABLE>
         </RESOURCE>
         <!-- The ProcessedObservation Resource also included-->
         <!-- in the Observation_Group-->
         <!-- describes each of the observations in the group -->
         <!-- included in the cone search-->
         <RESOURCE name="ProcessedObservation">
            <TABLE ID="ProcessedObservation">
              <DESCRIPTION>
                 This resource describes list of processed observations 
              </DESCRIPTION>
              <FIELD ID="Observation_Name" name="Observation_Name" datatype="char" ucd="ID_IMAGE">
                <DESCRIPTION>
                 "Name of the Observation" 
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="ReferenceNumber" name="ReferenceNumber" datatype="char" ucd="ID_IMAGE">
                <DESCRIPTION>
                  "Reference Number of the Image" 
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="Size_alpha" name="Size_alpha" datatype="float" precision="7" width="11" unit="deg" ucd="INST_DET_SIZE">
                <DESCRIPTION>
                   Observation range in alpha (angular) 
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="Size_delta" name="Size_delta" datatype="float" precision="F7" width="11" unit="deg" ucd="INST_DET_SIZE">
                <DESCRIPTION>
                   Observation range in delta (angular) 
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="PixelSize" name="Angular Pixel Size"  datatype="float" unit ="deg">
                <DESCRIPTION>
                   Pixel size measured in sky units
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="Origin" name="Origin" datatype="char">
                 <DESCRIPTION>
                   Data provider references
                 </DESCRIPTION>
              </FIELD>
              <FIELD ID="OriginalCoding" name="OriginalCoding" datatype="char">
                 <DESCRIPTION>
                   Image coding provided by the data producer
                 </DESCRIPTION>
              </FIELD>
              <FIELD ID="AvailableCodings" name="AvailableCodings" datatype="char">
                 <DESCRIPTION>
                  Codings which may be  produced on the fly
                 </DESCRIPTION>
              </FIELD>
              <FIELD ID="alpha" name="CentralPoint_RA" ucd="POS_EQ_RA_MAIN"  datatype="float" precision="F7" width="11" unit="deg">
                <DESCRIPTION>
                    Position of center	
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="delta" name="CentralPoint_DEC" ucd="POS_EQ_DEC_MAIN"  datatype="float" precision="F7" width="11" unit="deg">
                <DESCRIPTION>
                    Position of center	
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="date" name="DateAndTime"  datatype="char">
                <DESCRIPTION>
                    Observation date
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="AP" name="Position Angle"  datatype="float" precision="F7"  width="11" unit="deg">
                <DESCRIPTION>
                   Position Angle of the Y axis
                </DESCRIPTION>
              </FIELD>
             <DATA><TABLEDATA>
             <!-- Here we generally find several lines,  one by observation-->
               <TR><TD>DEEP2C-FI</TD><TD></TD><TD>0.655380</TD><TD>0.688248</TD><TD>0.000066</TD><TD>ESO</TD><TD>FITS</TD><TD>FITS</TD><TD>53.119485</TD><TD>-27.803630</TD><TD>1999-11-05</TD><TD>0.001375</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
         <!-- The storage Mapping ressource contains as many lines as the-->
         <!-- previous "Processed Observation" one It gives implementation-->
         <!-- details for the Observation. -->
         <!-- the link between records is made by the common Observation_Name-->
         <!-- field (here the Observation_Name field appears as a reference -->
         <!-- to the field defined in the "processedObservation" ressource-->
         <RESOURCE name="StorageMapping">
            <TABLE ID="StorageMapping">
              <DESCRIPTION>
                 This resource describes list of processed observations 
              </DESCRIPTION>
              <FIELD ref="Observation_Name" >
              </FIELD>
              <FIELD ID="Cutout" name="Organisation"  datatype="char">
                <DESCRIPTION>
                    Status of cutout availability 
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="number" name="NumberOfPatches"  datatype="int">
                <DESCRIPTION>
                     Number of subimages
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="size" name="Maximum size"  datatype="int">
                <DESCRIPTION>
                   Maximum size 
                </DESCRIPTION>
              </FIELD>
              <FIELD ID="Location" name="Location" datatype="char">
                 <DESCRIPTION>
                     File location
                 </DESCRIPTION>
              </FIELD> 
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FI</TD><TD>CUTOUTS</TD><TD>25</TD><TD>2048</TD><TD>file:/GOODS/DEEP2C-FI.fits</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
     </RESOURCE>
     <RESOURCE name="Observation_Group" >
     <INFO name ="OGtype" value="filter,epoch"/>
       <TABLE ref="Observation_Group">
        <DATA><TABLEDATA>
          <TR><TD>"filter"</TD><TD>RC162</TD></TR>
          <TR><TD>"epoch"</TD><TD>epoch1</TD></TR>
        </TABLEDATA></DATA>
       </TABLE>
         <RESOURCE name="Filter" >
           <TABLE ref="Filter">
            <DATA><TABLEDATA>
              <TR><TD>0.571000</TD><TD>0.731000</TD><TD></TD><TD>RC162</TD><TD></TD></TR>
            </TABLEDATA></DATA>
           </TABLE>
         </RESOURCE>
         <RESOURCE name="ProcessedObservation">
            <TABLE ref="ProcessedObservation">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FR</TD><TD></TD><TD>0.630168</TD><TD>0.641256</TD><TD>0.000066</TD><TD>ESO</TD><TD>FITS</TD><TD>FITS</TD><TD>53.107341</TD><TD>-27.793466</TD><TD>2000-10-26</TD><TD>0.007780</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
         <RESOURCE name="StorageMapping">
            <TABLE ref="StorageMapping">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FR</TD><TD>CUTOUTS</TD><TD>25</TD><TD>2048</TD><TD
>/GOODS/DEEP2C-FR.fits</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
     </RESOURCE>
     <RESOURCE name="Observation_Group" >
     <INFO name ="OGtype" value="filter,epoch"/>
       <TABLE ref="Observation_Group">
        <DATA><TABLEDATA>
          <TR><TD>"filter"</TD><TD>V89</TD></TR>
          <TR><TD>"epoch"</TD><TD>epoch1</TD></TR>
        </TABLEDATA></DATA>
       </TABLE>
         <RESOURCE name="Filter" >
           <TABLE ref="Filter">
            <DATA><TABLEDATA>
              <TR><TD>0.495000</TD><TD>0.585000</TD><TD></TD><TD>V89</TD><TD></TD></TR>
            </TABLEDATA></DATA>
           </TABLE>
         </RESOURCE>
         <RESOURCE name="ProcessedObservation">
            <TABLE ref="ProcessedObservation">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FV</TD><TD></TD><TD>0.634854</TD><TD>0.620532</TD><TD>0.000066</TD><TD>ESO</TD><TD>FITS</TD><TD>FITS</TD><TD>53.109618</TD><TD>-27.802574</TD><TD>2000-10-26</TD><TD>0.006580</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
         <RESOURCE name="StorageMapping">
            <TABLE ref="StorageMapping">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FV</TD><TD>CUTOUTS</TD><TD>25</TD><TD>2048</TD><TD
>/GOODS/DEEP2C-FV.fits</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
     </RESOURCE>
     <RESOURCE name="Observation_Group" >
     <INFO name ="OGtype" value="filter,epoch"/>
       <TABLE ref="Observation_Group">
        <DATA><TABLEDATA>
          <TR><TD>"filter"</TD><TD>U38</TD></TR>
          <TR><TD>"epoch"</TD><TD>epoch1</TD></TR>
        </TABLEDATA></DATA>
       </TABLE>
         <RESOURCE name="Filter" >
           <TABLE ref="Filter">
            <DATA><TABLEDATA>
              <TR><TD>0.344000</TD><TD>0.382000</TD><TD></TD><TD>U38</TD><TD></TD></TR>
            </TABLEDATA></DATA>
           </TABLE>
         </RESOURCE>
         <RESOURCE name="ProcessedObservation">
            <TABLE ref="ProcessedObservation">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FU</TD><TD></TD><TD>0.625284</TD><TD>0.639474</TD><TD>0.000066</TD><TD>ESO</TD><TD>FITS</TD><TD>FITS</TD><TD>53.105229</TD><TD>-27.797327</TD><TD>2000-10-26</TD><TD>0.008895</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
         <RESOURCE name="StorageMapping">
            <TABLE ref="StorageMapping">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FU</TD><TD>CUTOUTS</TD><TD>25</TD><TD>2048</TD><TD
>/GOODS/DEEP2C-FU.fits</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
     </RESOURCE>
     <RESOURCE name="Observation_Group" >
     <INFO name ="OGtype" value="filter,epoch"/>
       <TABLE ref="Observation_Group">
        <DATA><TABLEDATA>
          <TR><TD>"filter"</TD><TD>B99</TD></TR>
          <TR><TD>"epoch"</TD><TD>epoch1</TD></TR>
        </TABLEDATA></DATA>
       </TABLE>
         <RESOURCE name="Filter" >
           <TABLE ref="Filter">
            <DATA><TABLEDATA>
              <TR><TD>0.406000</TD><TD>0.506000</TD><TD></TD><TD>B99</TD><TD></TD></TR>
            </TABLEDATA></DATA>
           </TABLE>
         </RESOURCE>
         <RESOURCE name="ProcessedObservation">
            <TABLE ref="ProcessedObservation">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FB</TD><TD></TD><TD>0.601986</TD><TD>0.554598</TD><TD>0.000066</TD><TD>ESO</TD><TD>FITS</TD><TD>FITS</TD><TD>53.120442</TD><TD>-27.808151</TD><TD>2000-10-26</TD><TD>0.000870</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
         <RESOURCE name="StorageMapping">
            <TABLE ref="StorageMapping">
             <DATA><TABLEDATA>
               <TR><TD>DEEP2C-FB</TD><TD>CUTOUTS</TD><TD>25</TD><TD>2048</TD><TD
>/GOODS/DEEP2C-FB.fits</TD></TR>
             </TABLEDATA></DATA>
            </TABLE>
         </RESOURCE>
     </RESOURCE>
 </RESOURCE>
</VOTABLE>

-------------------------------------------------------------------------------

Some original metadata for that = FITS HEADER for the blue image
SIMPLE  =                    T          / file does conform to FITS standard
BITPIX  =                  -32          / number of bits per data pixel
NAXIS   =                    2          / number of data axes
NAXIS1  =                 9121          / length of data axis 1
NAXIS2  =                 8403          / length of data axis 2
MJD-OBS =       51843.31944900          / Obs start 2000-10-26T07:40:00.383 (day
ORIGIN  = 'EIS     '                    / ESO Imaging Survey
RA      =            53.439926          / 03:33:45.5 RA (J2000) at start (deg)
DEC     =            -27.80982          / -27:48:35 DEC (J2000) at start (deg)
DATE    = '2000-10-26T07:42:49'         / UT date and time when file was written
DATE-OBS= '2000-10-26T07:40:00.383'     / UT date and time of observation at sta
LST     =            19023.266          / 05:17:03.27 LST at start (sec)
UTC     =            27599.977          / 07:39:59.98 UTC at start (sec)
RADECSYS= 'FK5     '                    / Coordinate reference frame
OBJECT  = 'deep2c_FB'                   / Object name.
CRVAL1  =            53.122059          / [deg] X reference coordinate value
CRVAL2  =             -27.8132          / [deg] Y reference coordinate value
CTYPE1  = 'RA---COE'                    / Type of Sky projection
CTYPE2  = 'DEC--COE'                    / Sky projection.
CD1_1   = -6.60000000000000E-05         / [deg/pixel] Matrix rotation
CD1_2   =                  -0.          / [deg/pixel] Matrix rotation
CD2_1   =                  -0.          / [deg/pixel] Matrix rotation
CD2_2   = 6.60000000000000E-05          / [deg/pixel] Matrix rotation
TELESCOP= 'ESO-2.2 '                    / Telescope name.
INSTRUME= 'WFI     '                    / Instrument name.
EQUINOX =                2000.          / [year] Projection reference.
HANGLE  =     2.6027026000E+01          / [deg] Hour angle. Sud = 0.
FILTER  = 'B99     '                    / Filter.
RON     =     4.5000000000E+00          / [e-] Read Out Noise.
CRPIX1  =                4536.          / [pixel] X reference pixel
CRPIX2  =                4125.          / [pixel] Y reference pixel
JDAY    =    2451843.826081000          / [day] Jday of observation.
AIRMASS =    1.101322000000000          / [1/cos(zenith_distance)] Airmass.
EXPTIME =     1.00000000000000          / [sec] Exposure time.
EPOCH   =     2000.81781300000          / [year]
FLXSCALE=         1.0000000000          / Relative Flux Scale
GAIN    =     49093.6940510000          / [e-/ADU] Gain.
TOT-EXPT=             24546.85          / [sec] Total cumulative exposure
TOT-IMAG=                   30          / Total number of stacked images
PROJP1  =     -2.781320000E+01          / COE
PROJP2  = 0.00000000000000E+00          / COE
ZP      =             24.29485          / zero point
ZP_ERR  =                0.029          / error in the zero point
SEE_IMA =                 1.02          / seeing measured in the image
P_ID    =                   24          / EIS Product ID
DPR_TYPE= 'SCIENCE '                    / Type of image data
COMMENT --------------------------------------------------------
COMMENT This FITS file is part of the ESO Imaging Survey (EIS)
COMMENT data release or has been produced by one of the EIS
COMMENT on-line servers. The data is under copyright of ESO.
COMMENT In using this data for the preparation of scientific or
COMMENT other publications proper acknowledgement should be
COMMENT given to ESO and the EIS project.
COMMENT
COMMENT c) European Southern Observatory, 2001
COMMENT --------------------------------------------------------
COMMENT --------------------------------------------------------
COMMENT This FITS file is part of the ESO Imaging Survey (EIS)
COMMENT data release or has been produced by one of the EIS
COMMENT on-line servers. The data is under copyright of ESO.
COMMENT In using this data for the preparation of scientific or
COMMENT other publications proper acknowledgement should be
COMMENT given to ESO and the EIS project.
COMMENT
COMMENT c) European Southern Observatory, 2001
COMMENT --------------------------------------------------------
COMMENT FTU-1.43/2001-03-05T14:49:25/split.ftt
HISTORY FTU-1.43/2001-03-05/ADD: DPR_TYPE
HISTORY FTU-1.43/2001-03-05/ADD: DPR_TYPE





=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From - Mon Apr 21 22:30:23 2003
X-UIDL: 3e5baf6500000635
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3LKRAB6028602
	for <dal@ivoa.net>; Mon, 21 Apr 2003 22:27:10 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3LKR9R03090
	for <dal@ivoa.net>; Mon, 21 Apr 2003 22:27:09 +0200 (MEST)
Received: from cv3.cv.nrao.edu(192.33.115.2) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAm8aObg; Mon, 21 Apr 03 22:27:08 +0200
Received: from polaris.cv.nrao.edu (polaris.cv.nrao.edu [192.33.115.101])
	by cv3.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h3LKNvj11720;
	Mon, 21 Apr 2003 16:23:57 -0400
Received: from oak (oak.aoc.nrao.edu [146.88.1.137])
	by polaris.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h3LKNuZ19941;
	Mon, 21 Apr 2003 16:23:56 -0400
Date: Mon, 21 Apr 2003 14:23:55 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: Roy Williams <roy@cacr.caltech.edu>
cc: dal@ivoa.net
Subject: Re: SIAP2
In-Reply-To: <01f001c3083b$6ac98430$6b91d783@cacr.caltech.edu>
Message-ID: <Pine.LNX.4.44.0304211404300.3565-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.6, required 7,
	IN_REP_TO, SPAM_PHRASE_00_01, USER_AGENT_PINE)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Hi Roy -

> I'm not too sure if there is an exploder to send this to -- could you please
> make sure that my suggestions (below) goes to the right group who are
> specifying SIAP2?

This would be the DAL exploder.  I will copy this response there.  Some
yet to be specified subgroup of the IVOA DAL working group will specify
the next version of SIA.


> (1) Replicas
> In a SIAP service that I have built, the image dataset is available in
> multiple places and protocols. Therefore I have added a new keyword
> "dataserver". If this keyword is set to X, then it controls the nature of
> the URLs in the resulting table of images. In my case, I have values
> understood for attribute:
> -- if it is "http-cacr", then the URLs point to an address at
> cacr.caltech.edu with the form http://
> -- if it is "http-npaci", then the URLs point to an address at nvo.npaci.edu
> with the form http://
> -- if it is "srb-npaci", then the URLs point to an address with the form
> srb://

If I understand this correctly, a default query will output references
for all of the above, with the "dataserver" attribute set for each image
reference in the output votable.  If one then sets "dataserver=XX" in the
input query only images served by the named server/protocol will be listed.
Is this correct?

I guess the reason for this is to allow the server location to be understood
and specified without having to parse the URL.  We probably also need
the collection ID and dataset ID (which would be the same for all replicas)
to make this scheme work.

 
> (2) Logical names
> When images are downloaded to a local disk, I would like to know what to
> call the files. Currently my only option is file1.fits, file2.fits, ....,
> because there is only a URL, no logical file name (LFN). Some URL's are
> constructed as camcol=3&rerun=6 etc etc and not easy to convert to a
> reasonable file name. Some have .fit.gz and other suffixes that should not
> be part of the LFN. Thus if I want to run the same computation again, I do
> not know what files are already in the local cache. It would be really nice
> for the table of images to include a column for the logical name -- not
> necessarily mandatory, but with a specified VOX:UCD for it. "If I already
> have a file of this name, then I don't need to download the URL".

The Web-way of doing this is to cache things based on the URL string.
You wouldn't use this as a filename, but in some sort of index that points
to the filename.  This is the concept for the current SIA and is part
of the reason we have a static, fully specified URL acref.

There would be no harm in providing a suggested filename in the output
metadata (FITS writers commonly do this for example).  I'm not sure how much
this would accomplish here though, since we are not pretty-printing file
names for the user, and your client code would already have to deal with
services that don't include this optional attribute.

The default filename could also be based on the collection ID and dataset
ID, if we had those keywords.

	- Doug


From - Wed Apr 23 10:27:26 2003
X-UIDL: 3e5baf6500000647
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3MGpwhr002977;
	Tue, 22 Apr 2003 18:51:58 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3MGpwL09988;
	Tue, 22 Apr 2003 18:51:58 +0200 (MEST)
Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAskayGt; Tue, 22 Apr 03 18:51:55 +0200
Received: from aria (aria.stsci.edu [130.167.236.125])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AEA10626;
	Tue, 22 Apr 2003 12:50:35 -0400 (EDT)
Message-ID: <006001c308ef$4c1b2840$7deca782@stsci.edu>
From: "Robert Hanisch" <hanisch@stsci.edu>
To: <dal@ivoa.net>, <dm@ivoa.net>
Cc: <busko@stsci.edu>
Subject: spectral data models and SIA support for spectra
Date: Tue, 22 Apr 2003 12:50:35 -0400
Organization: Space Telescope Science Institute
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_005C_01C308CD.C4CAD190"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01C308CD.C4CAD190
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_005D_01C308CD.C4CAD190"


------=_NextPart_001_005D_01C308CD.C4CAD190
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all.  I asked Ivo Busko here at STScI to write up some thoughts on =
spectral data models.  He has implemented a general spectral analysis =
package called specview (see http://specview.stsci.edu) that deals with =
a large variety of spectral data formats, and I thought his experiences =
would be helpful.  I'm sure Ivo would be willing to engage in some =
dialog to help us out in this area.

Bob
------=_NextPart_001_005D_01C308CD.C4CAD190
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all.&nbsp; I asked Ivo Busko here at =
STScI to=20
write up some thoughts on spectral data models.&nbsp; He has implemented =
a=20
general spectral analysis package called specview (see <A=20
href=3D"http://specview.stsci.edu">http://specview.stsci.edu</A>) that =
deals with=20
a large variety of spectral data formats, and I thought his experiences =
would be=20
helpful.&nbsp; I'm sure Ivo would be willing to engage in some dialog to =
help us=20
out in this area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Bob</FONT></DIV></BODY></HTML>

------=_NextPart_001_005D_01C308CD.C4CAD190--

------=_NextPart_000_005C_01C308CD.C4CAD190
Content-Type: application/pdf;
	name="SpectralDM.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="SpectralDM.pdf"

JVBERi0xLjMNJeLjz9MNCjMyIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzNCANL0ggWyAx
MzQwIDM2MSBdIA0vTCA1MjE4MyANL0UgMjc3MzMgDS9OIDQgDS9UIDUxNDI1IA0+PiANZW5kb2Jq
DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTMyIDQ1IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDEyNDcgMDAwMDAgbg0KMDAw
MDAwMTcwMSAwMDAwMCBuDQowMDAwMDAxOTA4IDAwMDAwIG4NCjAwMDAwMDIxMDIgMDAwMDAgbg0K
MDAwMDAwMjQ2MSAwMDAwMCBuDQowMDAwMDAyOTQ2IDAwMDAwIG4NCjAwMDAwMDk1NjQgMDAwMDAg
bg0KMDAwMDAxMDAzOCAwMDAwMCBuDQowMDAwMDEwMjM3IDAwMDAwIG4NCjAwMDAwMTA0ODYgMDAw
MDAgbg0KMDAwMDAxMDc4MSAwMDAwMCBuDQowMDAwMDExMTI5IDAwMDAwIG4NCjAwMDAwMTEzODkg
MDAwMDAgbg0KMDAwMDAxMTc4NyAwMDAwMCBuDQowMDAwMDEyNTcxIDAwMDAwIG4NCjAwMDAwMTI5
NjYgMDAwMDAgbg0KMDAwMDAxMjk4NyAwMDAwMCBuDQowMDAwMDEzODY4IDAwMDAwIG4NCjAwMDAw
MTM4ODkgMDAwMDAgbg0KMDAwMDAxNDY5OCAwMDAwMCBuDQowMDAwMDE0NzE5IDAwMDAwIG4NCjAw
MDAwMTUzMzIgMDAwMDAgbg0KMDAwMDAxNTM1MyAwMDAwMCBuDQowMDAwMDE2MDA0IDAwMDAwIG4N
CjAwMDAwMTYxODQgMDAwMDAgbg0KMDAwMDAxNjQyMCAwMDAwMCBuDQowMDAwMDE2NDQxIDAwMDAw
IG4NCjAwMDAwMTczMjMgMDAwMDAgbg0KMDAwMDAxNzY0OCAwMDAwMCBuDQowMDAwMDE3ODkzIDAw
MDAwIG4NCjAwMDAwMTc5MTQgMDAwMDAgbg0KMDAwMDAxODU5NyAwMDAwMCBuDQowMDAwMDE4NjE4
IDAwMDAwIG4NCjAwMDAwMTkyNjMgMDAwMDAgbg0KMDAwMDAxOTI4NCAwMDAwMCBuDQowMDAwMDE5
NTYwIDAwMDAwIG4NCjAwMDAwMjE0NDkgMDAwMDAgbg0KMDAwMDAyMTUyNyAwMDAwMCBuDQowMDAw
MDIzMDg2IDAwMDAwIG4NCjAwMDAwMjM3MDIgMDAwMDAgbg0KMDAwMDAyMzk5MiAwMDAwMCBuDQow
MDAwMDI3Mzc5IDAwMDAwIG4NCjAwMDAwMDEzNDAgMDAwMDAgbg0KMDAwMDAwMTY4MCAwMDAwMCBu
DQp0cmFpbGVyDTw8DS9TaXplIDc3DS9JbmZvIDMwIDAgUiANL1Jvb3QgMzMgMCBSIA0vUHJldiA1
MTQxNSANL0lEWzxmZDE3ZjQ1OWZhYmZhNDc0MGM2MWZiY2Q5OWYxNzE4Yz48ODBmOTBmM2YzYmU5
ZjllN2ExYjI1YzhkM2IxMGU1M2E+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgIA0zMyAwIG9i
ag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAyOSAwIFIgDS9NZXRhZGF0YSAzMSAwIFIgDS9Q
YWdlTGFiZWxzIDI4IDAgUiANPj4gDWVuZG9iag03NSAwIG9iag08PCAvUyAxNTYgL0wgMjgzIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNzYgMCBSID4+IA1zdHJlYW0NCkiJYmBgYGZgYLVh
YGNg4BNl4GdAAH4GVqAoCwPHDAaGdRwqHAYnGBi2KTKgA0bfJQfZODZ8W+2z+jG35bGKz9eLWXWc
i9aWNnNkPj6X0yOykXeNQdu2l5/7PkA0uIR2dHRAmMahoRFgNqNYGphmSwPSMMuAgIuBYfF6IK0J
xFZgEVEGXtYL2k5LZHketYuIOTzhmBB48J74xNrWGwzMMQwMRxkYVBkYOG8IP7jOwHDdKYEPaEYE
A1MBA4P9uRnMkxk5fRTXqrFuUGm0k2QIYnGRdX3BtiGNSaoxIINthdRCNsYMZ2S/STMwHKwC0kxA
7A0QYAA3DkKIDWVuZHN0cmVhbQ1lbmRvYmoNNzYgMCBvYmoNMjQ4IA1lbmRvYmoNMzQgMCBvYmoN
PDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI5IDAgUiANL1Jlc291cmNlcyAzNSAwIFIgDS9Db250
ZW50cyBbIDQ5IDAgUiA1MSAwIFIgNTMgMCBSIDU1IDAgUiA1OSAwIFIgNjMgMCBSIDY1IDAgUiA2
NyAwIFIgXSANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5
MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv
VGV4dCAvSW1hZ2VCIF0gDS9Gb250IDw8IC9GMSA0MiAwIFIgL0YyIDQzIDAgUiAvRjMgMzcgMCBS
IC9GNCA0NiAwIFIgL0Y1IDU2IDAgUiAvRjYgNjAgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDc0
IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDY5IDAgUiA+PiANPj4gDWVuZG9iag0zNiAwIG9i
ag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDY5MyANL0NhcEhlaWdodCAwIA0v
RGVzY2VudCAtMjAwIA0vRmxhZ3MgMjYyMTc4IA0vRm9udEJCb3ggWyAtMzAxIC0yNTAgMTE2NCA5
NDYgXSANL0ZvbnROYW1lIC9KT0xGS0YrQ01CWDEwIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEx
NCANL1N0ZW1IIDQ3IA0vQ2hhclNldCAoL29uZS9JL24vdC9yL28vZC91L2MvaS90d28vaHlwaGVu
L0Qvcy9wL2UvYS9jb2xvbi9lbmRhc2gvUi93L2ZpL3NsYXNoL2wvXA1iL0wvZy95L0gvaC92L3Bl
cmlvZC9tL1MvZi9icmFja2V0bGVmdC9icmFja2V0cmlnaHQpDS9Gb250RmlsZTMgNzMgMCBSIA0+
PiANZW5kb2JqDTM3IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmly
c3RDaGFyIDMwIA0vTGFzdENoYXIgMTUwIA0vV2lkdGhzIFsgNjM5IDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAzODMgMzE5IDU3NSAwIDU3NSA1NzUgMCAwIDAgMCAwIDAgDTAgMzE5IDAgMCAw
IDAgMCAwIDAgMCAwIDg4MiAwIDAgMCA5MDAgNDM2IDAgMCA2OTIgMCAwIDAgMCAwIDg2MyANNjM5
IDAgMCAwIDAgMCAwIDAgMzE5IDAgMzE5IDAgMCAwIDU1OSA2MzkgNTExIDYzOSA1MjcgMzUxIDU3
NSA2MzkgDTMxOSAwIDAgMzE5IDk1OCA2MzkgNTc1IDYzOSAwIDQ3NCA0NTQgNDQ3IDYzOSA2MDcg
ODMxIDAgNjA3IDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDU3NSBdIA0vRW5jb2RpbmcgNDAgMCBSIA0vQmFzZUZvbnQgL0pPTEZLRitDTUJY
MTAgDS9Gb250RGVzY3JpcHRvciAzNiAwIFIgDT4+IA1lbmRvYmoNMzggMCBvYmoNPDwgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA2NTI2IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0K
SImclXlUFFcWxqtougpE1rZAqpiqHnUSE8WIxoUZEwWNcQFBFhciKpuArNKgIQg0S9NL0S2ggAra
sootmyJGUFwmIlkkyWSO4zKJDohLMig5GZlb+BidYtEzc3JO4kz/V33qvu/7fvfdWzhmbobhOG69
ysdrufd7M5Z6+7nNHvljisDggpO54DLREe1Bhqeqp8FS+K0teNlBuH27i/ywA2aG48tXL01ITE2K
joxKlk9f+obczd19gdwjLiIpOiwkXu4dkhwVEReSLD7Eyv0TwqIjklNnyT1iY+V+IxUKuV+EIiJp
Z0T4mKooOwHD4nDcCsN2YZiFGWYtwRxwjMIwGsemWGKuVlg0hnk6YwkYbmUlmYK9bjZT4oa/jbnj
HpZeVpuwEBpbJsbBSOwyHo6D2WPJdslJcxvzKPM684vmPdLJ0mDp58Q04gTxA7md/LtFsEWX5ULL
uglLJ3xrNdOKt7ozcedEwXqN9VmbaNuptn+2e8/urP0M+9sOQQ6PZAmy7kl+k1oohgLHFMcvneY4
fTnZanK3s6/zSXo23cBMZi67WLtEutz8TT67nL3OzeI8nz97HLjO5vnzh4EBvEmQmqCgAh/shm3d
D3slQoAwjQLShCaABdF3tv2M4SCfe5DNVKdmJNHJZbtq6w4aq5qiGvx9t0So89jmeP+CRGYmsliP
MA4Ri2JvoRvkZiW/go0l8+sv6quZ6nNaXTNnIlco+TMc3IBt//HCyXb9Uaalnde0cKadpIe2pIlD
x2GQAinZ/13r1XNHP+TZNM2ujARalZ9Um81qMvjsTBqRpM2o7xwjkH1NFQ6id68Hq7plHXBbNN9W
lBHKocpfcCFISOSQLdWl6XQ6RqfV8umM7LYYWEo87mn57FhTVrKRDdWqEtLo7TUZhysry45dCWj1
mIWsNiCcfZWQ4/5AbVSOuovslvULMtHbL9YJz8hIlVT2rVqXr1dzB2JCeSUzBeH+U18JLAmRJgpt
F0M8vN52bV8tn32UzVanZe2gU/fuLlexNs+x3vF+j3B7UD/ubBTdJFIpO68U/vGq+MI1Qeoc/gO1
s+wONgbwV/HN9Qvbnco2JocYNzKuyFJE+Wr3JfLXcq8cjz3Qe/JKVWNeQi0brs1W7KJTStMO5bE2
coE7AksGcXCqgCUVEnAVeqguxZmtUamJO3aUJzYZDxQXFrL6fPHH6Pl0dUzuUi9vLjOT12ro3AJ1
Qcnt6zCBhXWO/3uRzfNnp7tcXuh7ieKh/5e4OKq/u2tAhiNP/Y34404J3EG5lIHXf1TOIntwiIG1
4EqD5wnwBFuwZ/eX8noDXaQ2qLLc3kcyX3YDMstEkgX0OyXI+o9IyiLbrp5VxUzhHkMR919nQ5p4
eCsYqJtKsA4AKQu2PvOuZjEqtVql4bWHU7lH0y+juSiCRou3oWXIDjmwGaNmVXvUhcX3vgLZFfY8
mJWC5A49lh4FjqVfKaZ/v4zKz9elr05Ys2UTp1LpdOrRkKW3bgH5heJU2AsqZaWFe4tH6IlrCnw6
8RI4JIE68KE60aG15Ni5/CDeMyiBgItUnaIqPl6hiI+vUtTVVVXViS0fj/OJ4CQRVg1togr28wY9
XZK9T5muzsrSsOj7Z57SvAxeo6WV+7JLDuwpLjaIZeJwNJs+FjEkXpNA+9AkqorXJ7OrvefyMUws
abzC11zghg+SkZpMNzYmljA09vItTEsvr2nkTDGkm6akmRMPuQFPnvxowjuewJb7EiEQPKkkIi8u
d0vWbouc3JV8CoNWEIM/SWE2sF2XBmgg3P6KbJDU4605/h28obyx9FRNak1UjpbXadirlZeaO5n7
p3/v/oeNiwK8ORSAtkuVSl6roAWSGHEMtEkIMTpA+41l38h+PAruFBx+m4jUKj3YnaLFUxf4Vqb1
Iq859XLD9g6Qsoem14UPSCNfmJat4TNzWNQ1HC2FakekIUAjWEpt5ClHmx7cqRSmVTu03lv1AMLv
yf4pSOAbKoZEGVOD134UqG9IZD/eW1duUhxMSYvLDl9xKfRvQIENuEAMJ3sKFYj8ak5AUOrmrWzo
5uSQJTSyv/sGmH96qrWzkkV271JpwfznsVxqM99xjr7Etx9pZjtqT+xvZNrqozeXc6Uxe7yC6YXR
b85lXzQcEsZ7Ltj8vOnopvnPLwJMFQFtNAkrjfjxIQ+JMGXIi9qfpy1KY9I0qvQ8DoUN/5C6IWx3
oM5Z3C6Vp/VNjOmCVndc3C4bk6prDPnF+XquDZykwBMXkas0X61Xqek4fz5R3EaGpj/xJ5jTbTpt
K2dKJX3Si+qVHKoQisXPF7opRSmEuHIjRlYudFfASZMDcLehs99zQCZAkmBGgY6s1xe1s2BH9DfO
X7c6aAGScPezqf7DX39xje596zvkyA6bxVYRN/TKSG64ipQ9Edv6LquIFVwIcL7X932v+1+QpJTz
RrcoZE9s0hbVc1ADvuTj1lkrlq13nyYON6ZY2JdiGnI14Z/8JCQekwy5Dr1DlfNFSrV6pO8bPaRN
2zZ0zGCQD5onDvZWFAbzkRusgQWPgAOLYr4oQ8mrsnQcmpojd0c4swZtaIDzcAHWN3wKeN9s9JqR
S9fzmgNMGW84MqJYfreANw3hJhzYHkE2IGkcWkzFVpEvUrzIYEbAImBhOviCH2LADS3m0KR/yanR
GMKJMTYDxGdfpyw7z5323TfvHRpJPvSJDGITd/mtfY0RlVYaFopwu0xQ34CDSx8EVUuG5FAizhua
lZTsiZYwyHkci/Ee2V8SM5+rhkNJxDxl7JusG+QSY/wpAlxrAxBXxlUTCZAiHe56Cf3IS7vXRrrp
Kl5DE7SboG1MMKD635RXeVRT6RWXgeRRq3YUXzvmOe+JS0WhakVEHHGZcana1lFHRwGRRQggqKAo
oGBYosn7khC2QBAIkYQlrCJYpSiu1YFxLWMHt2rF0VN1PDLH3he/9Jx+SdRxzng8p/kz53t3+d3f
/d17YZzJVbhhnUPbjv38I6IQfaiVafsOKZo5Sxzlg0qaOODvUY+LXofinxnnzfpB3qtQhohhsmk1
Zu2hEH+HjpLiZRkgySJMsIwgFZzZv7neY4/woJtOLjkcqWMKUUEpB59Srbnar1kLxUd/oUxgImci
jZSLr6ceaGTR3HLKowO7YY+srctwUJOjdOsbzv/nu9/jiQb2rcpBJvUTXtRvXnPKi8F/xjPxdByO
w2EG9oVVvTfNf2vknI31lQUaLQ4cuvpdBavwnG5W675lqyxiRcwCFMVEzUeaGO516XEG7oIM6n1P
fmQHQe4b0lyHrju0dTs11y5cUApduPS9T8g0Gzw66RX9Rve7QrI9Ko3uBmu2u5xDXG6a43Bppm5o
XrlUyOawiXZ7N4i91hsOe4nUHIXT3sH72mTjOXATdlpc2sANJt1zhdPgRU9dv3qtfAk6J2W7iuvM
zVsNW5Nj0zcuuLai/3nv1es6TlWA1I0S4XOqTY+6SW2UG6P4ECbcF2miuPhm6inKiOGGlRMYIw0C
64Txrp1LDv5OkKXj4XghE+Ckr1BHNSL9v9kGkoR0GopgNgW+GzehnNDGxc/S8AqCMTVC1S1XkFsn
0Uai9DsYHPiGpgpqGwoZb1+rmjrVDUwDWatI4tR41FHNCc0qCuT//UCUodVmFTE6TYEulzDXOlSk
sl0Tv6lAy2VC79ZLSNHypgJC1esS40BxIuJTczi81XZe5KCMsyw1QkCNK+yxTqeLs3hVCoPnxteK
Sw08X8odVKj4FImt4n2hlVHafSo+Vy742J58tLdQxeczepRfwQmdVDXqGLC3QUyQMo6JC1KrCEbU
AArZxtnmkb1hkOX86GSzdZbJLoYbB1ytUfCQhjDsTTRvGV6Cf4dn4AjC9Cl4GiyGZeANvhDK4rv4
Pu2NJfdBD8Xw28t3/gXjFuJCXI4/9p/KvZGhQ2bodmgeHB9whV1whYZAMQyBQbeePfW6jz/m8Iu3
tPx9JFZAGQ0HnQLYLwZf5BkUgvAg7Ms5U8BrB66Y4FdGoZYk8gx8jPCXZ65CaT4Ng0/ehZHgLflZ
TqHgTbp3maUpr7CW9SnVT33EPK+AUSeKkE6WxWcTfV8jD08IY0KSGnu2c3hdIb3GgN16IU0CJTDm
1sMnMNoPFwTuxZ6egeyZ5M3HP2fWxYdFbCtJUSk5mFpEp8Ru3p/MrMs+Vlpb2dB6yhi+UmePNnP0
tmQjAeekEbrIACTg8CCaN/DY7JEGO+yHXjF1EBUbNay6qBYZmAfgth9PWLx9NvbinmXQT6r6LvRJ
HmPxP/FEFl96F3zN1+wMvOYQ2NcykUeRS5ASH2hHsU3cISmK/4NkGYpsi2KlbafldUxf2e2aPKQj
cy0rh+cWymNSk5ig7BOP0rmMm6k9QQ1fVIwaRkbmtJoRZ8yJPXC5Z63ZoxeeCx/ReKRF9KfSTafO
Sa6eutAHnxjxrNA8Vq5Cch1TgrQVHGxwaGgOz+/NYWNWiWoTItqmM2T19vWcdfLTvm2cbv+JvVfT
3D0eVefU5dREu1cmFsXFSRau/8x/yzxt51p25SlFD9/sXsRnIwWTgXJSORxCpaEcXb5KrctnVRpN
w0k21tIj7WfgFzefwgfPlt72N7ya82R9DaiEBS0uzSYo6IcCMg2nWANoG4hTcLLIJAY/fWkDeDPl
ZqQs4ir3I9kOCcEyFqWPZSPtu+JzdIw5NuDYFSOpsUjfaO9mA9KX57JqXTWqYMC7NA776e3DCcYR
jH7j1C2rxa5bu2k8dvInPiF4sAlWscLw90v9UAp7gjsm3wP14BGIy1iNARUelkAv1YCOOrpYGqyM
ZWKC1Srp6y62e620elpcKqzBrlYX4Tatb6muvaxyJ/IaH8knMgkr1apE8rqLr0zcIclWyJVyFi+3
7cSrBbVIrkdqtaT2LDIR6wrpYhJUcJjT+tcVKErPwR7bS1FKvlZRwpSptXotwdXFdH6M02X5y+2u
Lz2Jy7PlR4paGeIxIZ5PYLYsd3q8xBviUiRyRbbd42RbBJ4hZIj4XGWeVlJ3DpkdHpfYYSAeI8j7
s5VIWswZF2HOtgD7CTIRr+HzNe9+ez13X3QxByE2qyhLo8ksYfTq/BKixwGCFmbb8n7yJ7l32Rew
gBwxPs571ySsps1p1dJd6ZlyOavkyY9RIn1uff7fu7/iip234r7cfbJZ8/DgFVWhR5rKq832e/f/
/2jYGJkxzQKbK6sf/NU4ov3b4Ifgf6XX5LFbBvf+QUfmVod3MJUX9Le4M0mrqZVJclnc/qNaFkKo
dtQqbWFbN60/EMwELA5ZmmBIM9eUG8zF+xo2qLim6k5dPdN5dtN0Lpq0tmydYpHijwnu82OTvtwo
mf0kqfviscMdFWwOzKInUj6fxYYGRTQdP91+BwLy2GEyo8wgjDdCdPuIFxeh4o5HJ8wXhtJwlcLj
ZaJ46mpBThBne2SiVKoCfXWHu8eeHaXt679h4Jc/PCXnjMek77E4MCwkdTenwQdoiKAqkEp3gD3T
erqgijnanBhVxZkjNKsiJNHKFVtC2fidUXFrmFBpVct2Lr0SacolZIXYkHhBZoKGhy0ml8Y78OVD
V8DCr+kIhTwhQ5JYvqvGbCiruzyvdS4ePpXI/Id45Pde4A6SehhSVJSJFFnK/XIlO2XLsr3RzFrf
I+AH/rfbTxZ289ImjuSX3C6McuRHbFdcJNvhh6fppRRM1Iks1KLs/E5O+OHtXHE85dHZvCXMvIbB
g8dOwjT2eOoF4p6jjfUmDirdcDiVipSyNDY4ITQ57H+sV3tQU+kVL4Tkoiu0S7yd9d6Ze7Hrk3Ws
dnVtp2u7YGXZXZX6gNUuy0NEGIEEQsI7IYIQcm8uAXmlvJJAQkKCEB4RxRW0srsulg6idXG79d1d
/7CWXWW/Sz+n9EtAbHfsznTamcz9I/fcc37fOec7v99BR7H2ZNGZ/eUj/YSL+9h+inKYejrPk13u
wlgHXZfPavOeHTHdBMLMPrYboHhMwBNoIpgrWNPDqAdIy/j/eAV6Eo9DAAYCTwFBS20JV1asLS3R
0itSNrJHyQOJHS45nX6GHesmdCYcrK26aTlBfl0LyUPoHv5jwkOyvNABNt2sNvsAv7Ev7whAOL8C
ByIHXAT8RXfPnBmoaGCPNVBFmjyVjJA35rTbG4xtrsOd0dtfi15OQez1tM/gJBarZiM80qJ3kLOR
fYNseR/tyMZCvfIxGB5sBXs+vNkK2NYg23DONRB2rWtY/A2QgTfwTezfWtt1zgYLXV/dausj77Cr
5RlMaqGMLiqRSxPJNdW4tLe/vIW8Pz4+6SpwyVrpE93dlc0kV8kyFbRaU6YuIvINRY21Lcdbm4qc
h3LiSg8mUJ0JCRUKcn14+C/izEmWbFpVmHckhRDPpBmSHDlUZH5qfCKx7eE+EAgWPxq63qUc2m+j
bNG72V2kLJ7VHaNT9dkOJ6FnW5uMFBDDWXxV+NC50z2ugQr6I9Ft4MdujvrVgbV0IEqft098gO84
SBoX8O+DSvw260jrppqUR4y7yS1xkckFNAOmRP96NZoWEtY1xLWT1mEtcwJpsQg1e4oGO7BHExcu
jdZF7aGg8vmG78rYDsZTwZOe5YkXukHAdNC16e1j4vtgO78Lh8GeWL+vKUWtaV5w4TzPtZFdXXMu
3tJU9tLiKT3fgztlJmmaIiMzw5zpsFlMTmquNWCCufEun+X1nfjl8OO3x8R/B4c93td5vE/WeE4S
jMUWb36nTM4aMqkGvfG37YQ1zyiV5uVkvntBOnLtk0tfUOInM+v97FltEklWlkTSlmW3t7XZUYxZ
lxc8ZgeZbp/pMQHoA404w5VVVRD6iY9rq6nRITdn8vBQuUTFSsnknZxOiSZ3C1OrVhE5yqKSYxRc
DgOFvBx7fnI7Bzk72dHHaPueJvdr7NLvhJPL3XvziNx8Ta7HyPYRZyLtdkZrR0aHFey5pIXEzvig
wgoQsu0zb+P/IcQ5zkJakJZ2PQ2BdMOdqH3eqijMQcB3dIenM9BvKSXuAr7gAQ5N/2P5/8s+AXux
b7VkUj59RxlaF0uGxcTvlNLia4+Rclg4XuC3wYs7/z+4nwtnHsLVf4cQrLbwG7xjr+OGgE8FR3Cw
dPU0DIAvhkAfNPTwR6+ARSBg6q9ATMFMGIPHx5lOZ9CyAfZiN9HLnm8boE63D5r6yIGTingrbY1n
dycRyWyUIo6KVcRJDpCBMNqB6Jxf5pZZgqbHQeMN8edgG/gLPmT/wD5EXr34KhTCgO1bQhOTjP0Z
Ht7RGYl9fgWV7qhPF4gs5CH025oQp8ihxQ/G5ptw4nhpHP0kZSEDJ4Y5K9k+NLdtzaXqdWyu++ch
hFhyjB6iaRwXf87/4CIO3/yOj/kRBZa0QSh+YFMdHP05Cf1/FAJ/CF98sAr4X+4/aTfTFSANh8ux
1DypIotSqlIzYsiwXfcQQ7xw+cYf/+TeFI06dHaNw/G0yNNj07fFp8Ab13GwHnvovvfpcY5lOKqc
ySnKJKSmQnOzpd7pTLPHhyVHxCsp8STwxSD9jPpM3zn8Z2dfQSxm5l9rCepslZ8BBeghvgcOgWjc
rPlzwTZif0ri1i3JI7dyKUM5oz86L9Bf8gr0Sp2upYXiOJZrbvFPGDjFmEiAnf7DlXPpHUX19BHn
oeqEan/x5N66CMOHRJe1/zbwrdyYxlHFuhqWm9seprzLQ5mWLVJR5ZqjxZpyf1vSQbaQhIFJEXtT
GqXtCtqZaSu9ovRHWFferUCMu9oIpA7wU6PPo3FAWAQg1MOILzvgy2CHTMT8LD14rcZfcQvaMfj9
+0XdE7aJS9SIbB8Wmp50OIL9ooma0w9Cd9AcKYhzefIzfCMGViyoB5RvgMHVz5IYjm16782wLZrB
YQrcmn9znS3/CQ1DsK3sBrDuwoDtk6dDU23iCSTXeaWA3wRu4zWtTSfHvHJdLmHkZNb7nC4fjUkX
UyfPJZDO0aiplbAa+gGnsNTgUevWXrbZswuk79XKyYxEHZeOzEf1pWkGGqyAQKis4soMpEFfU6uf
34LmIjbPhAr4WXAPbz7rMHR5IyokjIKUxHK6XOSimzHnSYhSVlumojbAmjUooKae4SqJ9l7W6Ako
2a/NItMlcwFdjVpVLV1ZWpd+PHczLHtpHTAKy5AI1i+Ye/FponWcZ5s4W1+eivR6EPxGqKysKEH4
uCq0TUyB7q+gS6jWe/+qmIM8zyxCh089r/PwShHe0dPzQZvV0d3fMOgFnpnu2WyiOZ0K+TZpq1UF
RMFRVVkptXPr1ilhcS3LVRENDTVGnQdI5lvaAjI7RsdlIOPLOiZykH4I8ZhIVhuzZ9nu936tzSbT
MM7q0FlJu1vLtKG7qqg4ZmggzPbOi1co+6Fqde8B/2q1oaCUKC4uzGA8t6XjAmcm23sZbQcyj8rj
7PJ55Ih3m2/yClThmwL+VZTuUeuQrpF8Wt+8GE6nQDgcTGO+jDjKaMuKqFWQgQJgFmpqtXo9YXWx
LfOw8xfqe6aFTUHbWMgTnzKV8kipatk+hTT8HRIxd3Mu7dBXmxsJa26jPEehSo91J58d7R8ZaaPm
RChr4ZeiUcwvQvqTX4nX1HmKZChh8yh4VaSGm4UW0VdVLS7gSwKRCDqfBAiL1agJCOVxhAPcEDWB
SKFMBBcXZ8dBfySQRYHBAOlNltcIeA2oxs1PNAosUGGe+aUZtjcBSZ0IHqzHKNO2vO/5zC5Z5Fg8
/oK5ZsmSceOSACrqN1FRkUv5R/g/BwD0Ku+bCmVuZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmoNPDwg
DS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2OTMgDS9DYXBIZWlnaHQgNjc2IA0vRGVz
Y2VudCAtMjA1IA0vRmxhZ3MgNiANL0ZvbnRCQm94IFsgLTI1MSAtMjUwIDEwMDkgOTY5IF0gDS9G
b250TmFtZSAvSk9MRk1FK0NNUjEwIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDY5IA0vWEhlaWdo
dCA0MzAgDS9TdGVtSCAzMSANL0NoYXJTZXQgKC9JL24vdC9oL2kvcy9kL28vYy91L20vZS9yL2Iv
YS9sL1MvcC92L3cvaHlwaGVuL3ovcGFyZW5sZWZ0L2NvbG9uL3NsYXNoL1wNcGVyaW9kL3BhcmVu
cmlnaHQvZi9jb21tYS95L2cvZmkvai9UL1YvTy9rL3gvQS9xL3R3by9EL0MvTC9XL29uZS9mZi9I
L1UvXA1lbmRhc2gvZmwvRS9GL3F1b3RlZGJsbGVmdC9xdW90ZWRibHJpZ2h0L3F1b3RlcmlnaHQv
Qi9SL1EvTi9NL0ovRy9uaW5lL2ZcDW91ci9mZmkvUCkNL0ZvbnRGaWxlMyAzOCAwIFIgDT4+IA1l
bmRvYmoNNDAgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0Jhc2VFbmNvZGluZyAvV2luQW5z
aUVuY29kaW5nIA0vRGlmZmVyZW5jZXMgWyAxOSAvTHNsYXNoIC9sc2xhc2ggL21pbnVzIC9mcmFj
dGlvbiAvYnJldmUgL2Nhcm9uIC9kb3RsZXNzaSAvZG90YWNjZW50IA0vaHVuZ2FydW1sYXV0IC9v
Z29uZWsgL3JpbmcgL2ZpIC9mbCBdIA0+PiANZW5kb2JqDTQxIDAgb2JqDTw8IA0vVHlwZSAvRm9u
dERlc2NyaXB0b3IgDS9Bc2NlbnQgNjkzIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFn
cyAzNCANL0ZvbnRCQm94IFsgLTMzIC0yNTAgOTQ1IDc0OSBdIA0vRm9udE5hbWUgL0pPTEZJRitD
TVIxNyANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA1MyANL1N0ZW1IIDI2IA0vQ2hhclNldCAoL0cv
ZS9uL3IvaS9jL3MvcC90L2EvbC9kL3UpDS9Gb250RmlsZTMgNzAgMCBSIA0+PiANZW5kb2JqDTQy
IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDcxIA0v
TGFzdENoYXIgMTE3IA0vV2lkdGhzIFsgNzI2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgNDU5IDAgNDA2IDUxMSANNDA2IDAgMCAwIDI1MCAwIDAgMjUw
IDAgNTExIDAgNTExIDAgMzU0IDM1OSAzNTQgNTExIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29k
aW5nIA0vQmFzZUZvbnQgL0pPTEZJRitDTVIxNyANL0ZvbnREZXNjcmlwdG9yIDQxIDAgUiANPj4g
DWVuZG9iag00MyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0
Q2hhciA0OCANL0xhc3RDaGFyIDExOCANL1dpZHRocyBbIDQ5MCAwIDQ5MCA0OTAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCA3MzQgNjkzIDAgMCAwIDAgMCAwIDM1MyAwIA0wIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNzIgDTAgNTE3
IDI3MiAwIDAgNDkwIDU0NCAwIDM4MSAzODYgMCA1NDQgNTE3IF0gDS9FbmNvZGluZyAvV2luQW5z
aUVuY29kaW5nIA0vQmFzZUZvbnQgL0pPTEZKQStDTVIxMiANL0ZvbnREZXNjcmlwdG9yIDQ0IDAg
UiANPj4gDWVuZG9iag00NCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50
IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCANL0ZsYWdzIDM0IA0vRm9udEJCb3ggWyAtMzQg
LTI1MSA5ODggNzUwIF0gDS9Gb250TmFtZSAvSk9MRkpBK0NNUjEyIA0vSXRhbGljQW5nbGUgMCAN
L1N0ZW1WIDY1IA0vU3RlbUggMjkgDS9DaGFyU2V0ICgvSS92L28vQi91L3Mvay9BL3Avci9pL2wv
dHdvL3plcm8vdGhyZWUpDS9Gb250RmlsZTMgNjggMCBSIA0+PiANZW5kb2JqDTQ1IDAgb2JqDTw8
IA0vVHlwZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDEgL2ZmIC9mZmkgNDAgL3BhcmVubGVm
dCAvcGFyZW5yaWdodCA0NCAvY29tbWEgL2h5cGhlbiAvcGVyaW9kIC9zbGFzaCANNDkgL29uZSAv
dHdvIDUyIC9mb3VyIDU3IC9uaW5lIC9jb2xvbiA2NSAvQSAvQiAvQyAvRCAvRSAvRiAvRyAvSCAN
L0kgL0ogNzYgL0wgL00gL04gL08gL1AgL1EgL1IgL1MgL1QgL1UgL1YgL1cgOTcgL2EgL2IgL2Mg
L2QgL2UgL2YgDS9nIC9oIC9pIC9qIC9rIC9sIC9tIC9uIC9vIC9wIC9xIC9yIC9zIC90IC91IC92
IC93IC94IC95IC96IDEzMyANL2VuZGFzaCAxNDEgL3F1b3RlZGJsbGVmdCAvcXVvdGVkYmxyaWdo
dCAxNDQgL3F1b3RlcmlnaHQgMTQ3IC9maSANL2ZsIF0gDT4+IA1lbmRvYmoNNDYgMCBvYmoNPDwg
DS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMSANL0xhc3RDaGFyIDE0
OCANL1dpZHRocyBbIDU4MyA4MzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg
MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgDTMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg
MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyANMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg
Mzg5IDM4OSAzMzMgMzMzIDI3OCAzMzMgMjc4IDUwMCAzMzMgNTAwIA01MDAgMzMzIDUwMCAzMzMg
MzMzIDMzMyAzMzMgNTAwIDI3OCAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyA3NTAgDTcwOCA3MjIg
NzY0IDY4MSA2NTMgNzg1IDc1MCAzNjEgNTE0IDMzMyA2MjUgOTE3IDc1MCA3NzggNjgxIDc3OCAN
NzM2IDU1NiA3MjIgNzUwIDc1MCAxMDI4IDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg
MzMzIDUwMCANNTU2IDQ0NCA1NTYgNDQ0IDMwNiA1MDAgNTU2IDI3OCAzMDYgNTI4IDI3OCA4MzMg
NTU2IDUwMCA1NTYgNTI4IA0zOTIgMzk0IDM4OSA1NTYgNTI4IDcyMiA1MjggNTI4IDQ0NCAzMzMg
MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgDTMzMyAzMzMgMzMzIDUwMCAzMzMgMzMzIDMzMyAzMzMg
MzMzIDMzMyAzMzMgNTAwIDUwMCAzMzMgMjc4IDMzMyANMzMzIDU1NiA1NTYgXSANL0VuY29kaW5n
IDQ1IDAgUiANL0Jhc2VGb250IC9KT0xGTUUrQ01SMTAgDS9Gb250RGVzY3JpcHRvciAzOSAwIFIg
DS9Ub1VuaWNvZGUgNDcgMCBSIA0+PiANZW5kb2JqDTQ3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlIC9MZW5ndGggMzIxID4+IA1zdHJlYW0NCkiJVFHLboMwELzzFXts1YNtIAlIFoemipRD
H2rS3h17SZGKsQw55O+7i2mqHoDxeHZ2mRXb/dPedxOItzjYA07Qdt5FHIdLtAgnPHceVA6us9Ny
mt+2NwEEFR+u44T93rcDaJ2Jd7ocp3iFu135IO9BvEaHsfNnuDuqj08iDpcQvrFHP4GEpgGHbSa2
zya8mB5BcNkfd7wGhHw+q6Xx4HAMxmI0/oygpWpA12UD6N3/u2yVKk6t/TIxS8rdo5QN4TzhgnBB
xVpK+mS6WhHOpWK+lgnXTUbei0v965la6LxiUT07ECbCMtEmYsv23LbIUw/FBKsLkwgy1yUrykSU
rCjZY7VJBHusWbFJijUrKke4wjQgK+piiYH/Si0Tpxk5GN7WLWN7iZHin1c6p8z5dh5vWw9D4Dj5
yX4EGAArg5rNCmVuZHN0cmVhbQ1lbmRvYmoNNDggMCBvYmoNODAzIA1lbmRvYmoNNDkgMCBvYmoN
PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0OCAwIFIgPj4gDXN0cmVhbQ0KSImMVMlu
2zAQvfsrdCSLiuYmiuqtQdEgvUa3JAdHVlKhthLIcoL26/uGi+w0BVr4YGk085aZIS/a1fqrKlTR
PqxULbSqbCHxy8/K+cK5Rpii3a9k8bhaX16r4vGwKqWQ0hZth2j7urphl/3Iy4b1vFSiYdPAy0oY
1vHSSC8cO/CyFoo9490Jz/punjaUYtkOIaXZlqpTaOYKJXjRjRc6187TkXK6OfxNIac/8Lv2Gzzo
5AHkVaWjh/SsKy0aVzjjhddSBScQ7xWpv2FXL1wb9kRCSfEFGVDsyJXE34ErFLMfMYWoYFyR81IL
qWtXtF9iL2of4T6j3omKnFYwOvHSw9EQok0065mW0iThJgm3wliXhKdnL4UtKocWOBIdW+4ijQKg
grGaXQESfCM3Go0rG6ieyA2NYXvEAOBA5S/QASNj4raJW4pGNipyp+fIXRmh7MJdmdQxTNpiQzyh
At2y71xiTmSSpGBeBvWgJx2G1uC4Rx9oOSg8cq1FEGsNaIKDhiLbAIOZltSrbiLNboG9xz4oEVCs
8khY2HsCoJLthtoCwvwJ71bWCAT+LGfb7yjeAPQYKBNj0rclOBpeZh5z4D3j9XNW1b3QxKulKIG9
gknXYZUCxyk/gyWbWfoi7Q+8VH88ywvxMgxTFlhbbTTtY1jHtN3DL47sim3mAWMvdaVCV1Q4i6B3
+W83dH/JvGVcYrrGImOeU+qn9frAq7jjDZL6WJjqXzjJHFLwVcTUGTjxKaUNImVsI+gx/t1yJAp0
t64g8Yrj1Gjqv27ixUBqQmJPMXeq7zO79mGS4W33lCTvuT0JHZMfIHiHpaBmPJBjMnOdu/Jvax9p
naj4lWu6OvowifZDOql1nMAD3V46jFfiuHY9rZes4wFQtAp0esJaQw5gnsMrbQUtbCi634Vdga89
2TZQlj+R8FqdoU3pIg1fx4AVVicD508hrw9n0S/FmecnUB01ckiB8TGV9QksV5wn6NoiY2GjRddp
0d8p28XbvQmH/qQq524yWmrfm3YsTdjEJahpMjSIN96ysn6mu1yfPJ23DjD6vxXf/RZgAJD/k8QN
ZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag03MzEgDWVuZG9iag01MSAwIG9iag08PCAvRmlsdGVy
IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDUwIDAgUiA+PiANc3RyZWFtDQpIiYxUu3LjMAzs8xUpyZmj
hg89+6uuSeNJk6RgLMfJRbY8kpxMvuN++LAAqTi55iqJILBYLEBsfl3Za+MKX5XXm59XtrC2qq83
26s79aidK5yK2tiiVEc59fKZdal+aBOauqjVizaePsfPq2U6y+GgfdGpnXaWrkMgyzIjriopYAtz
XOIw7mey+VrFNYsJNSL/yHnYkaH06mmcDlEQAlL+4y+Q8/KSLvbI5Yn+8pyqWWAJRZUrSeTftG/I
jZlOc0rX55iYYdZSpRZNylVqzLdRP2yynsFDzzs1X1CBjlyKtxTrLcV+6IqMJwKyLBTfjU8sBxli
asK8TJFrA33bIemjNqRip34z53wJPgXToL/af2tt7aS1G1aDOgfdLdQ4iWHSrmiBzacB0HR5gBc6
9sg8RSayR22J28TNq+hMrWc5LHc+sKPxXUPGKYWIy4rrUX3OJt2UuWCnFIuyWGTbUL18Svyhl+v+
m/4TcaKhWfH5g9lxLdMIuP6At5fBl4y3usWgTMtZcOOAEBR5o10gh5TvS22T4S6YzzbIRBh+YkH6
8KZr0dEQQODSMEdjOk/adIlRgL73KjncamLcqJt7zQNDln5HXcDE0IQ6NHSfMI7UDa92EzAA9g5M
CMjmI0YXmvW7TGJIABlIAPaidMjx+TZTfgaRjoBWA3oTMNSJWManbrTcONuS9ZWm+DJZnwllDfAU
XAWG31XK50KbMmDuN7k074nxmXljNkOdxmblVWFX9LttTvtNu/GLdvPFq77YkqW08F37IJPou5a8
Fwr22BHjqwxSS/MyHjW/b1LRt1iZ/FIbjPHns6fgBBa1d0T1A96WAHjrtESHHwS/BUtuZ4lGay3o
9xkNfZhf9kfpmeM1adkhAXzx5NXn02GQVONJPA5ipX3nRUMsn0adcmYnbLjgLbum7PTSWiVbnbDl
akyEh5VHHOZRJqHOWqTaV1JJ1nkkKg9/BRgA/sx+Yg1lbmRzdHJlYW0NZW5kb2JqDTUyIDAgb2Jq
DTUzNSANZW5kb2JqDTUzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTIg
MCBSID4+IA1zdHJlYW0NCkiJfFSxctswDN39FR7JgTyRFCVq7F2mLB3q69LLYEtynEsqK7UV19+R
Hw5AAZSs5DISeHx4eCC4uV9la2W0dXa9uVupTGeZN+tNvfojdlJZowvRSgiXYiuVMdqIf1JVOhdP
cHTaiU5mcHqUypkKskdCdRDISrh9hoDVVhxajAQg+itVqUNCEl9K15wgXB8LvFA5EvMf6+GZ6Vnd
SaoC8s+cZ7I9NFM50NNEupZw3MUjy05tpY4I2bMbNZck4VwZFDpAOL6wVNY1CwdHJScUZgG/x3aL
uS3OlAD4LU3QlfiJ/ng49wPdZ0XH29bJITpp+bC5XxntCxvn7PM057wc5/wDmEvE7kBQiHoTgYsO
WahfIyqHQP1CkQVwgX+vOX+O+kLKHCmOT8SDpBTYY6CCAFGNDVqyHCmw81QXDQ8FEDY3uhm7xXQe
AxC34ipVDuBEesJ8BmUuEibu5+2M8aFr2lhwxhgRzxIGY0SLDZSORkylXfCA5BuHqKxl697oYmS9
YjTM/Bj4FrUfB4kvHCeophF+saqzV+6Mn2/d+Nqh54AT/hWP01N+k8rTzGbLdQEWF8jYb3YFWbFY
f9h+eoLjLtP5yLsUrTaTnrTrA+93w/9Gj3Y4i5ObvhouyGiuW4/CU90tLlX5aSe6RSe75ddyo5ou
nZEr0DO9MZl/rtfRxYFppx8tm747liCthRzP5yQfPgQYAPSsMzkNZW5kc3RyZWFtDWVuZG9iag01
NCAwIG9iag01NzMgDWVuZG9iag01NSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu
Z3RoIDU0IDAgUiA+PiANc3RyZWFtDQpIiWxUuXLbMBDt9RUsgZkAwckjtcaFy4RdJoVN0XIyMm1H
UpxU+Yt8b/bAQse4IrF4+/YBbxfj7co1xtuQUzOuV8ZZ53IzTquv6kGbzmb1rI336qc2MQ42qgMs
g/XqccaIs6368qJN8ICcp1/aZBvUd8BE+AIEAW+AbJ3t1UY7gN0RofDAKiagO9taNrtCIEQL7W4Z
OjHrM9YvlLPVJmVEjtr0UInpqsSScll53tKyng9Pd6V8DwQ+0REkzIRlf9nMGwh1EYodqSTcRQwD
/LyxECGs1yb7d+dlC90n/W28XX28yY1vxoeVt2loGxNsjAHNceiL+qvHH4CJgnE+NK56l1o2Lxid
bKfWUG7o4WePOlBdyLCa0aespgPU96gl2VSqe+tDOC9qs4vM+e+zzq4j7TkmOGEacCWqU1XU9dhS
KZ46yjMDuTOQO0nNoKllMakNrBHXj+QI3NWR2wBNBoSHC7qnTqPrTz2ej+4vFSu5m+hb4mRPgr5t
684eufp3Umu1M46UEBJKwMAXLF1jr/nanVE94aD0NU8IydR6qg+Q1WVAl7UkL1M9P/dIoNHiyEsR
Sb0OlJPc2TXJljzgSWbfzif5ssteeUi5X6U/BYLtTB5Lw2JpP6j5N2dJuOC5i8t4HbC3HV4lUZNG
Gbr73Wmyout5tnD79Hi8S73Dmb94Cq6fpUEc6K7mWzIYuUCdFue05JdM3nzCQ+ZqgTxHc40LV30Q
jkX+scqkffn+QRzJleonf+il/S/AAKmkL18NZW5kc3RyZWFtDWVuZG9iag01NiAwIG9iag08PCAN
L1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAxMjcgDS9MYXN0Q2hhciAx
MjcgDS9XaWR0aHMgWyA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9u
dCAvSk9MRk5KK0NNU1kxMCANL0ZvbnREZXNjcmlwdG9yIDU3IDAgUiANPj4gDWVuZG9iag01NyAw
IG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDAgDS9DYXBIZWlnaHQgMCAN
L0Rlc2NlbnQgMCANL0ZsYWdzIDk2IA0vRm9udEJCb3ggWyAtMjkgLTk2MCAxMTE2IDc3NSBdIA0v
Rm9udE5hbWUgL0pPTEZOSitDTVNZMTAgDS9JdGFsaWNBbmdsZSAtMTQuMDM1IA0vU3RlbVYgODUg
DS9TdGVtSCA0MCANL0NoYXJTZXQgKC9idWxsZXQpDS9Gb250RmlsZTMgNzIgMCBSIA0+PiANZW5k
b2JqDTU4IDAgb2JqDTgwNCANZW5kb2JqDTU5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
IC9MZW5ndGggNTggMCBSID4+IA1zdHJlYW0NCkiJXFTLbtswELzrIwoduUDF8CVK6q1tWiBFL60F
9NDk4EhO7MKPxpWd5jsC9HszS1KKa+QQkbs7Ozs7dKakUr7O2y77KYb96kheerGar6kwdSWdmJOS
tdiSNtKKHrdNKSuxjOcVFRo59+m4fqLCKr5ZpYI/VEojBioUDvtDvNyQk1osSGvEtmQd7gaurEOL
kJOiv6lo0G7KTSxOU14BuIekwnkLBi1ZsAyhw8ilsMZhmEcyJaoxiscpoa0i1S6Cxqn3/3fC9FZX
oDMspxqwNsgcyGgEnoJ6E2mk1wju7uim/ZKpHGIZa/L2MitYdmei7P0cMqqoExpZdA+VRtxR4YG0
p6KWpdiltA3C1stmygedwBLzNeg3C0ewMIppdEdek4EmC+LyR+R5NYIuHg5jeLyh1IRbxMOWjI0a
h348ti3R6YS41c1JxpLJlBopR4JkPuGkDmwTbMZNEx0C4xN4Bl+MZxnku/hsc523dxlUVFXNYnrl
JzGTlv9Qq0rxnQxP0g1hqXFAL94s+otuTpVYp4sxcMs+1kwvCMEpsZJdAhX6d4mCixQmBs5OBMoq
MrjC0pxycVqtAgmGrUM3C7Rntiqw2U+woBHXImVg8ooN21FY3XJMmAclKo47ZeOuozIR8T7Fcfaw
QHQGA2IPTPxTmz1kVvpc4Q/NXZ2bCvHS58bjiTQ+7zbZxdVG55e77Fv2ocWsPs2qZKMaHUrHb1OB
lbNcjfYubzcZS2BZAfHX9NT+OhWrqRXXT0rZqNTzOtDHnsJcLHS357cDu8zT7ofJuihtwhNs2By3
ZAyEeeJCDYiPXKfF+6+zNn5dza4p1b7lpAZJJoEW2Kq45Fv+heuDNc8bzoNwhYYLjHPnT7fUcYRY
FZzTRJa2cnFR/HAjmEmbt2L9+t/6Eh+3I0AqGBO78X59VslPp2SPmJRQsBNqnsbW5UmrDVupngje
p/9Bx8DPljU+HvlFNlPVSJidV8Ew4acIuFpsdwlhG1fgp9w0+whx5Ndrp+PJINbxxQ+CizwvjBvP
JDeown3lww9F8Hwl+kU3YvSL/rzpcsQd6OZFgAEAsNx2TA1lbmRzdHJlYW0NZW5kb2JqDTYwIDAg
b2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDUwIA0vTGFz
dENoYXIgMTIwIA0vV2lkdGhzIFsgNTI1IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDUyNSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCA1MjUg
XSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSk9MR0FDK0NNVFQxMCAN
L0ZvbnREZXNjcmlwdG9yIDYxIDAgUiANPj4gDWVuZG9iag02MSAwIG9iag08PCANL1R5cGUgL0Zv
bnREZXNjcmlwdG9yIA0vQXNjZW50IDYxMCANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAwIA0vRmxh
Z3MgMzIgDS9Gb250QkJveCBbIC00IC0yMzUgNzMxIDgwMCBdIA0vRm9udE5hbWUgL0pPTEdBQytD
TVRUMTAgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgNjkgDS9YSGVpZ2h0IDQzMCANL1N0ZW1IIDYx
IA0vQ2hhclNldCAoL3gvdHdvL2QpDS9Gb250RmlsZTMgNzEgMCBSIA0+PiANZW5kb2JqDTYyIDAg
b2JqDTYwNSANZW5kb2JqDTYzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg
NjIgMCBSID4+IA1zdHJlYW0NCkiJjFS5ctswEJ20+gqVQEEMARA8elVuoy5OAVMXZyhRI1L2+O/z
dhdQHCVFKnCvt8fb5fZlVa4La1yo1tvNqihNWYb1tl/9UB/aeuPUXhe+q02d5UkX1qr7iIfEHcyN
NyHpL1n/SfoOHyddwhrFusvmB+oChTNWnYZkmXVRlY4tnekIJ0B71YWzwKG4poJV0h3ImbLvvmTJ
kJB8G1QGPpBIGFmxUHALx16j7wx5Z6S/2nv7XUBlW3jfdNEZr/a9JEXZqR3f1sDMSS7aOYTlmiap
KVLqRlkOLTb65zbz4B3xQDTUnfBw0JWpEFhiGrczBKfiImNIXxgkujlpZKi4wLI2jXrXrsWz19ai
zpummX5S9SRGhuvF9sCYaEadheNwEbRjCp91EMcSbg8jeQdjs/65gp3IkmuJ2Rvhnlpapkf8c6SE
XEWbnnFI5cZlmC4IranQVyW5pcC7uPbae0inL3OV/ea5yljjTBAdINBiiSADhgF0xBt4Gm+EEniT
6xZyL35gQo1jvFIxAXmpFZoISUfmhdmmnRblnjlHIldoWpmNkMc7QhnP8UguFbUTx+m/oOaUHrOI
2FUfKl5W1g3n1FFCmoeM+aofzW0T4jD/c/kaJ1O6Mf81j7eW8TZqXJJ2R3zR3NF/+hIqG6YS+1fx
+oLQXiIWoRzrAIatSs5R23SPtoHtu2iv6cIkMgG860YNSfWBAE9XR8fGP460RWz99megJBxwFV32
oCNnetuOL9LWplW2oOEFYokUHfi2fMfSegrBFaWqr7lYsQ8pnSzp8/7J/5Vm+0uAAQCbzzaIDWVu
ZHN0cmVhbQ1lbmRvYmoNNjQgMCBvYmoNNTY3IA1lbmRvYmoNNjUgMCBvYmoNPDwgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgL0xlbmd0aCA2NCAwIFIgPj4gDXN0cmVhbQ0KSIl0lM9S3DAMxu95ihytmdr4
T7xOemY6nZ5zAw5sCCwdGrawwOyJh+gLV7Ilh9mBy24sf/r0sxSnuVCXCrTzJqg30IPa3eMqmE5N
4J3xagc6+MEk3HVBXeMmRZ8x6jrTqy14Sj3iOkTMOrDXbqaIRQXnOXquskf2WapMIrcUSFivOoHF
36r7AzqZoYII7SKYT3gIE9X8FzQVehGBxEF/cOHVUg4hFevhvmaqOHv2Fako1jVBHQvMHjT2NKn5
Elhm4Gr81Zz9iK1rx9tGB+OdbzVuBd+O541tx6lR7zD+RlEoImcsaixtI7213YZEF8pp6ND8HNGG
Hh+e6eS5ZqSahBDVdEBgF7F/HQJ95/JdcbatdmYTV+dYnEfQfZ6EUzO6bowjO995fKBBWDR+Ik2/
xreywQn3+cRJTRJ/4ID8H6EPWOQbGgRaS8JCji43FuGw9bKBFb3vZZg+t/xDwQMZUYYU3CL+upfN
GFoUU83BiadqyCouQ4CRGs1rSV4Bv9j4rAMeH1Kp9rJMp0oBWFZyA7qzNN2fj4DaSJeWZqPzJPMA
kW6dYCoTnF/BJRobva5yhIELDbnHbkDmPdBLnUWFMimm6qt4mnlGAwMmbC2lZcRQLlUoJq+wcfUl
SerUSvIXEXBLBnWTHU/zrqlwhio1ZL/yb/MN8/IaBjU9cCmRMiT/Cci/+UYs6rknocsnKUBrw2h1
JzjChxk+T0cCuwpCn0FD9w7j+XvpLRmtwtq9q/8CDADDDjUZDWVuZHN0cmVhbQ1lbmRvYmoNNjYg
MCBvYmoNMTk4IA1lbmRvYmoNNjcgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0
aCA2NiAwIFIgPj4gDXN0cmVhbQ0KSIlMjj1OA0EMhfs5xZR2YeOxZ3cn1EmKiHI6RIGWTQTFgkIi
yEVy3njERqKy9Px+vroLEimxmsa6DiQs0qVYx/AMe6SBezjP4wkpKSu8+zU2+PSbOMGMwhm+kcx6
HuB1kY9IK9enpovr0y9S57Gv+8MTzb8c9zXX2yO+1F142Fp0gH3wJtVIyvaPTYY/tqs3innqCQuv
HEizD/z4YhEHnebpuMAcLm20wL09L+2ZdSiRjIv0rV5aMSSsH2FTw02AAQCgtj0eDWVuZHN0cmVh
bQ1lbmRvYmoNNjggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNzk3IC9T
dWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIl0VXtUFNcdnnHZnW1EmmCmHmfszKY5OfWVGImP
ED3yrAQEkqCNFhUhyDP74rWwkT3uAi47e3dxAXkILLuwwA6PBFcRoUUJGqJHiBpNIKXWRmtoTaTm
1LR38HIOHTRN8k/+nDm/e7/X75vBMb9FGI7jS2LeiN0eE7YmIi5hfdDCC0agcWGZn7DC/1dZ6Ogj
7WyJFP76lzD4mXMrCH0gtgjHt++I0Gj1uVkZmfmKlRGrFOuDgzcrwlRpuVmpKWpFXEp+ZpoqJV98
UCp2alKz0vL1LynClEpFwsKJPEVCWl5ari7t4BNEDMeewbClOPYbHFuNYTEYFotjb+LYThx7G8ee
FjliBGbCZvBCHC7SLBqWPC05IbnnF+33iTRIOiXbJjsxPz+WHhigc81SLrxvElZPSoRd8DPylvlm
xiRz652IlkT6rUj1q+msJtYUhzBqdVV4byQTcvJa3jB95+zwKM/2TthnRimUjD4n341xQryINV4E
k59SfwWfN37MXGk619VP+0bzNzaz9QlgaxT1OggxxjNoUVFsUSYdAK7DR/eglMeH7sHsWxIhFm4l
C2SW90p3mQ7JS8oSgIpGcbKO1ktj7R45XAsVF4b/RUHi5S+QHMmjVm7ccwZUuNsbur1FzZoSDlgt
zNXmkcFx+svhyHWbEsMSdrAoCemkeQJOBOg67s7AFzxwyfQVD351Gu75pwTGQkS+Zy23llAmB3Ay
g7Ivfb9bg5ZFZSbuDW79RM12m3lnL8XrXJq8HENa0N1wKIGL/z797T/CbqxpYu60Xfjsz9RU8Ojq
34bFh6d2lTa4PQ2d3XnHC4484eK7Bxx0z3jxqiLLTnUyqzqQZdFa5QHzeKq8GPAwmRciXeLCzMaS
deVcpYE2cJZDZhalzX1teEeTs8O6XE3YL9lBD+39E+DaWZ5IseW6vVQlsDvqmUG4XAodsvNovdRx
GHAWSrUH5DLiidYp4KW9NwDXKp6I0YM+A4uahRYSytFtKSqWifivZX4o4l9zwdM8DplJeHta0j8b
QqpdxI0KUzo75yXSLaYIplAt+Msg+dWdb26G/wUtrme/dl4bm6Bub7iFljFoO7pOQjvRY686w8BA
2YPejb+P3v0qkrAr0V3yAFfVw0IevkF8c3bzttfiw1axAfPz06F+gJ8V84YrbkqgSnhInqiomWBa
eBmXt1EMW7UB2PNYdQsx8SONUKZALbN7boNOuvMO4DwsX0CEWmpOsAEKwAvyU3DpfRzilyUwXJgj
23WtmpwCnVblKfJ0OdtbGMSgeFJNjB07ksiiNiLJCGIWPBIN5enaUcC9v+BRueMkK/gRAfMYd1kk
KMi6Yd4p/KF4Zw90krayahtVcXmkupq5dvGMzW2T8wRXmCPSzdkD7Pmsmmiy1pUcogoL9VYGPY8C
pYKOQKxRqiauVpclsnPun8KKKsQwvSLsjsNggP0PMXbhoy3Napd6eYOuymig9AazbmG0bQh00P12
wPWLo1ol6NM8FjwrPfVEbehsDPkzIEMLIGd/AhJgahGCXHjnJOwUG34AZpOQXPVvsUP+a59DgejZ
B2ugDD51fwYGMigbJZHpSY1DalY7YP34NOUDl7oGmH7vmcYP6JOn9Qc72K79IDadygRxOfuYvZr9
RWm0aFzb3HfobR6ucwkvtuAPx2HjpARyKJh8jA/DiVxn38ExGhLf3ockXPriDMJf2RdbbmGvfO/U
p5VlB9i57B9EtI+IS8yPLKx9iFBDNgNbbSMz0DnU7KMnLr6M/NDiqA3blOr65kI2v7XY5aVEDviY
RQxvhUtM7r9TErgFGsj7p6a/qLYD61GmtPzQES2lbjU2ulz1HZ1ab/Im9bqiI4wVSmSI+sFH5PnR
x/Oijx3XH/eokAjnanvFFcaIrUEml7DJifcMQP2ABN4UtpBO4DCVFhWUlDFtSmXluzRakhG9ywgy
fZlst+b9ssGS88Z6S1uh3FlcX6ChknP3vhK91/eggCl3ApvVJj/KlQMLbQRmPYvEHwUw1zhsNncT
46gC9oZG+T7fCGiivxsenRrJ7i45xmZ0aSuj6+SqyvDjF6ku9+BXEK98SWlnSm1VoIKuBQ4n+yQQ
kSctbgs2DlPHJfAjIZz8v8goYlNSZGiw+Y8fMvBvBHpuQf4ksASxaDURBzI6s5kcT9/hc3RTN+DF
hrQ2+gC1noBsjZQnokqrhlgofN8Wk1ugedwp5EuEtfAueaylqX/scUHUBqCkdcXAvl8syGnOoTJS
JZzZfJh5AdUiP/iB1HzcChxUu0/87orjubuBls7mgD1eHL9QU66sY+Hz6JHU4LCb6+iqSntTFRug
c8+GuFF7A9TUyFBKLcG4I/QYPu//C/6p8cWuY/7+443+S5jXG3YnH32W2Wyt/8M8+b8BAH2Wi9wK
ZW5kc3RyZWFtDWVuZG9iag02OSAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNl
IA0vU00gMC4wMiANL1RSMiAvRGVmYXVsdCANPj4gDWVuZG9iag03MCAwIG9iag08PCAvRmlsdGVy
IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE0NjcgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpI
iXyUe1ATRxzH7xLIRcH4GE9bTu/ilLZYRaRVqY7CqIhVROShVm2FECJEiUkElKgDYoCQuwTyAEmI
EQIcIr4oWhGtMaJS0bHWVx9WO7bWvqxWnLF7uLT0Uh1rZ5zO/rU7+/vu9/Pb/S6KBAgQFEWHLExc
FLcgbsLchOTIKP8CyREoNzqAGxM8ai2seDKvrzgQjB0Kpg33jhFFjkAEKBoXP1et0W1QZmXnScPm
jpdGTp8eJZ2tUmxQymXrpQmyvGyFSpbHT3KkKWq5UpGnmySdnZMjTfZX5EqTFbmKDRsVmU9PRFAk
DEHmIEisAFmIIAkIkoggSQiSIkQkvEEEQ2rRcLQMfSRIETQKvhEuEvYEhAd8FogHqgcGeqL/kgyg
2rquLSzYynLjWbTzS27eRWEfClbhH1VYekgWM+YuZTSEepbJpKC0e7DvzNuyqAUYFMBR23NC4awr
wMmPGZd/A4G3xkNqF1lkZoxVxA7G7KZAMeamTaUGmi4qIdOiAntWJh6MJmAMjIATYAaUgYkwHMTe
vNFyppXK2LlbbSEsJpObkgwgij6N3gW2uOqu3nChh86BDN9NtxD0gxr8InNA1k7uW5NerSRmJics
WLPHaHU02Hc3FezYbCij6XLqfP0p9wHiRFdaFJWGLTHG6lNU4kXZuhWKkOi7+b4ub+sZD5lm3i3v
IOp9zhvUaV0ytlijL8xgTnaQyxrxKQlpqSsy2zr3OHxn95LHm7sq95rFvKXI4x/o3cBz5bob3XcB
yK4KQS94hBeomWx1g95ha6k4cGX+qehxkePhSPjqL5N7wbBWgO2opCtKSmi60EDN0CZvSifio7tB
GJh4vau7/WxBqoeS6F3c2y6gbvOLurxCcLQvBtdi3VWlqyhYiFkMGRdmEK+HTYavwNE/R9y/3XHR
ZqHmYGCIPZDFlmy3Hqe4J9iy/iu4SqfJ20SqlMqyAmL9a7UgBbwPxDVsZ5s2q4FybGTKdSHPIfJr
QawLbb4ASnxCbjgowisrGXN1SO/SH6BoXNQbcCgc9euExyCg43G9rZQxltDGIgM5Pz9VuZxIT2/s
0FA5Xqb7WIipFgehtq/2HiIudcbDABMlkTIsF9QGxt5Ce3mUCK4f9+h25eUX6PLy3QUNnl3uBhIO
gkk84Gm7H7AVUxjK4kktZm48wjQRjYcZYwPFcxmtBylOhPn1+oLa/hEL71uIw6Btgc960/9CaQdf
ynYwxka+NN5Q2U5JeBtSF/rQBzJ5wHfAGdxb/C0cPDNjsXwrST8UwcHPdeB/dFiCPfqCDkjFfjr9
+eXr9gWrSKj/n40SuJwFU13cZDf6wAecF4RAA2fhTzUSMVnLxxof8fvDO2AMGDHlXmjiyrVyNXUN
exFH9TL1+ZwVdzL17W1kpWX/nhPEtU8nQxEUxU+amZW585iKKvQwVhd/rQN/bm16ivzAC7BLQvAW
2IbfO3z3C5uNLreRTH6JNiR3V3Ftjce2e++6OmXM2tnZxSQNUBEUv7QTnbyFFi9jbOYB5xYxR/2R
FByx8G/1XSfadBBsOygEPdwM/Fm6txaR5YbtxeUG8f51q02bCSiUJyVF9m5sKaXOF3oM9Tqxo8iT
nxUiy10aMSXn4h0d6SxnTHpCT9ObKBiK6Uy0lU++3UJaq2obrdViTd0B7Wnige/U115Nc2ENpWrN
tsns4tSaec5zIayz6+Ef1jfXmckyk4WuIKqYip3U0ybo3RzJgul16H0fIPkPYwIXhgMpC6UgQScy
hmZHTjOKt3wP92MFDAwA4u79Z6+TZ3QpWJzmQ9l6ed2PpD+OY9uevRxwjPs3iwuxqNVzZk8v+eQk
CW5hcIi/b4eaGbmJgqnYe0w6qyYLHU3aq8TtfVfr7ZRpkggEPc8oeIJJtrj6YlzQUwPUdhFMr8LI
+vnVTsdA8CB2sC/IVR0c7HMEDyGTBpc660aSU9dmDovA/x4AyQnzmgplbmRzdHJlYW0NZW5kb2Jq
DTcxIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTI1IC9TdWJ0eXBlIC9U
eXBlMUMgPj4gDXN0cmVhbQ0KSIliZGBhYmBkZOTz8vdxd3TWdvYNCTE0AInI/pBm/CHO8kOGR6z9
d/3P/J9bWL/L8X9XFVzxo0+IgYmR0c3HOb+gsigzPaNEQcNZU8HQ0tJcwTE3tSgzOTFPwTexJCM1
N7EEyMlRCM5PzkwtqdRTcMzJUQgC6ShWCEotTi0qS02B2ggEwgyuDJFg9zAwMWQyXGeM5es+8aPj
BOP+J99nXWA+d1S0qbm1rVYqZ0n3bLnvz9nWTJqyWn4p+7zuhZkZ3RX5cr+b2I7te31t22aOU4d3
nr4t9Z1H7dpvvt9cNpZmacsb5ixYNGf59LYZTZPkds7ateqQ9N0bscauUYGeIfJ8rSdCTnw/f+I7
6wmh9Re+T7wgXPP9117R9O7azXJX2GYv6V61srC7Vj7ux0S2Va1TM+Wc2KqLunNyl3bPlN/x24hN
eM+KrKTZCdK/GbV1fgv/Fniq9fXw1mUrlst/z2ZxYQ+Os7Bz8b/05PXFMxdP7wkOkQN66vvJE4zL
fmQyf9/8vUj0O9t3DdbNbDOXda9cVdhdI/+bk62mqDs3Z2H3MnlHNfsPrEsXAh1QBJUpBFq8DGjx
ZrbvXL81fgv8NmVNRoh+52SbtQRoTll3jvzD7/xPfvOz5pcC5ZZ0zwLJwe1IZuNrmPbj+7TfwVPY
fldOYpdb4D515oz/PJwnuC5w/1goAhBgAPuN6HgKZW5kc3RyZWFtDWVuZG9iag03MiAwIG9iag08
PCAvTGVuZ3RoIDIyMCAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCgEABAEAAQEBDkpPTEZO
SitDTVNZMTAAAQEBJPgbAfgXBB7hSgNfDAL4HAwWbv5U+vD5mwX3JQ/3KBGm91QSAAIBAUZMQ29w
eXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5LiBBbGwgUmlnaHRz
IFJlc2VydmVkQ01TWTEwAAAAAHQAAgEBAicO+IjDoPfvnwHD+BcD+E/3jhX2M+Ii+wE2MiIg4zT0
9wHg5PQeDnWh+T+hBvsQkAceoEN5AAH/DAmzCuALs5oMDAplbmRzdHJlYW0NZW5kb2JqDTczIDAg
b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzI5NSAvU3VidHlwZSAvVHlwZTFD
ID4+IA1zdHJlYW0NCkiJbFVrUBRXGu1mmOkBZYiMrXGa7R6VRxB0VcxusNYXyuCqoIIo4iAPZQVR
lIcjbxEcAlxAwAcirwF8MeDM8mZa0JI1ihpTYsVkraQ2a0l2NYsVVsWv8bK6DYmJm+yfrur+7jnf
d06fey9JWFsRJEkq1qxfp1mrcV/p5x28YP74F7XAkMJUa8Fx8jR8FRc7Whe+0khhpj2sn3LF0X6r
A2FFkpp1K/ftT0mI2RWdpP5gpZt6gZfX79Ur9kYlxOyIiFP7RSRFR+2NSBJf9qgD9+2IiUpKmade
sWePOmAckagOiEqMStBF7fyxKUESCivCgSQYgnAmCDeSmEsQniTxB4JYShDecsLPmgiUEiEEsZcg
9hGEizg5QREc4U2kEL3kPHI3ec3KyyrZipdEWk+y9rD2s/5S6ic1yVxlpbIR6rp8oVwv52222PTa
0rbltiOTTk/6++Rlkw12H9m1KxYr/N+8vh+0WTHxBO8h8hR8IoF74E0P4U/mUOL3E/H9COaTX8N8
CRx+QHdGm8LDo6PDw03RnZ0mUyerUONiw6vAWvK2ECARikY30CXlqLRQVZt2MkOXm5GhZ8fsX8+T
5h5C+gLVwcqsCkPJqdOlIgzxgp7vqiXhEEySwMtRCV2HTsRn5aMj2WzAUiekYw5qa2WVfYU117mx
CsxpqeKuEdTD9IygvC6Ox2pK5IApcA1mtvDkNXACDbASoQISaK0s72D22owjcn3WcpTGYFcZ33ql
s7tZDrJvbvPfqYCafR/PxHZz/RZsuJTe0NRW13slojL9KNtwoeWkmXlo8V2uifL1WcXhUBwhzTyE
8g+qUoQVP9sB7/9kiWD1a09wu/WvfXpD3BgmRNGDPAmu4ChMB1cJuI4q6bFBTGiFlRRshTlgD7th
P54DNA7hxry1MsgbG6SFQXCh7vwt2aeHMwUf852nwuShzbHbWd9tnmn+jALiEA+tPJRPMM+C+zBL
MnpEZAaCl+VFuaFwJtwNFUdxWiBwOb4P5WKB+kVhYgqquOUp6mQ6n6K8FtFiAlrhPm79PwXRije2
TPNPcmZJoGO8oUxsGOmGQplQkTdS5JWJvDIR3v4UWRiLCG8X4TIRTtgY34HDDV4yOh3Oib9Ok5OK
F2JfxklUzYh0YZhEIUyYy7tzCgPjDO1ZRJY5gQejGYy8w7ipkA1z1DD3H73KNDDDf2gwgi0FHxYt
8Q9EH2EvDtx1NMgbL396RzWMrb7BG9ix995yyorNT1EH0yHOaJ7QbqSUvWAjq+hCMUauKRole6v+
iEIGYtgDXTc/bmdenvq2si4DHdYVHM4s4LS5cQf2Muuz73Xkcvknc+4WlGQMbDKGV8oVWbzwutPh
tiV0CO4OLe1Wfi64CAtp7GyU7jgeeLFf1Xn+5vdfDcdgx3o28SjKNzANqKSeg7VUDTqeklNQcDiL
3R4mtWxcc3wbgz1Wus9a0xxqOMD1hFw8AmSiXPn4UXJVXp1Ofjr9THyoalu8ZvYy7FELbjlsdQEq
OcAkIn0Sh9dQySi7+nhRUdkx1mKRhtx5rG9nwOsmSIdBsvjr+TXcD+HGxf2vrPpJmNovAQsupvtn
v7J63o+9XqdT/7uAFhcEjGbT2Mv/+Wur2f7gJRMzoZf+WW/ey8P6RphrdmgCm6XiDl0EMqVOsP0r
vQeFPmcvyWrLUUN9Jsrk/AvRqXoVxFKDqz7FbgFY8bFnmCn5nLHJ0NEoiipiS883FZYzX5gilnEx
lJJflYfLsrGzyh3eS7n7Fd/eUcemwgLag3L/bWZC8A5TFxCwsKK3mFWIQxiE35hhY5/DiBh6AmRQ
AlOVqbBbcKbBQmGfHKmWulmGdnJjQzxVWVNVXVkjV3bmHOsJGmTA7dm3wMGMuU+ws/fWuIOJXCnu
o+EoZTp36UIfAwqE7Xy0aFP8Ti4yLjQrlvHZefX0YdHBN0GOCfo2wb6NbIGp4A1TJDAmuNMpafm6
bNVbaQ+xvHQj9l2BKSzHM554wDz4XSPIyyrEMKUU5GfmsuvityUHM5hD4Gr5C4JpQJuq8vJOceOy
eEEyIWu8QQnIRGmEMlV4ytN+R1ArJ7x4VxreQil7WrduKd3NYJdZnuKR9/4/PeCD/ksNZ4xcCAVr
S6V4LYzQuJhKyYzctIzBCgR2A5fQ1bOtXMcF/oSRudYWG1c3rixqarq+DdY1w2Iz2ST2zvlOIkRC
HF13Ap0z6j/f2suZ/7S5WsPgRYuc8BSs+n4OfAgLO0eqqpNRbmp+bpqe26YLiF3D4JkFMOMy12xd
1FrYYWiWt51tK7/AgE0Rnh5dOJ7CjkideJ4942G/2QFs/u0MxCDYK4fAhqc1WlmhqbvIwrTcntil
i+AZUDylfIHthmVg9eXxMyUlKL+MTc/KSU5WhZuSzzY2Gdo7dnUvccNEBJayLsu1X4j3Bg41g8e/
7pkhqd2h6YkPSGAVSNAjn4fKl1lwDAJoT/RZdzf67NEjtHr7drTak8OKw3Si5XL+GQac+h4M8AnN
6ZVcY6Wh6GShPD83P1uvSqhKOXu2qqahPtUUmq7Niw5jy1MiDCsY7LRpiU9kbWRTErcvWr9bp0o/
GtIWyypHicw8b906VXDfctCCz4PrA405t1ZfZM8HrkfuTHwoKszlwsqyWqpVJ46eLj3G3sRBtHgc
GUGK/HbtDMLT8OQQi+XGLVTBKdDbVIg5/yHt4eKeeyHgabwGyqkXQa2u7sEbow6wBfBY9k5AlENj
vRotVXj+RlEL03o9v+A8JwKiKCAf9ty6aNAtY3H9L+o/3oE8DPcNwnyH/zZe9TFNnGGcrmkPWdcR
j9Ost9yBMjBbJiwxcR/KCEhckLlNKx8DMVAcsMp3OwSGQAzQ3l2LrQWKEigI2olYGF/l1vDhBwsh
0Q0dw02zhJkMl2xjJOQ99pKwtwUHBE32x90fd889z/N7Pn6/9x6AUOiDRnAWaIRYAka4XY95Zm/c
/eFVl6GP/GpIz6BmfYjhc7XCHWIgvTPlqTT2OToHqKcuhcc3RMAbeImBZjGaWL+iniQ7vjEgBRrU
M50oScRGIr9jSk8e6Q43bilIWbn8XsVdTp54JqwZ13hnS2HYZlj/4309Nh/fGxgal3A8j5otDDGe
JPccSY5R0/hD4IXB8LWtG8fkG/Jy98L5vIyeW+i1zsUeic+j8OnNUfwR1+Ar62gGfmLha7SPQBEy
B/fCt0Nfg69A31+DwXtg38wceJmC52EMAXEWeM042aHGTrqrqc/mIvv6SjJaaFsmq0xU7GGhF8Qp
OYzlQYBDEN1Q9WygzymQCx4RTRzX0ED19gybWsg7Nw/DrTAgKi66NIkdTabLrSzXpPgOThAo/cNY
Rv9ABZKZ1//20GnoExgYHnuqSEPjv7vWeOokvcRtGrLlkIuNqIhWsFPpofAFIEcVGN2GVj4S+74N
yP+iGKaoJFuR2lFot3fYekaO2eOiVAkxGgp3AgkG311XKbf3dbSBvJMXGysdAtmxtbsvZRKUoRvy
ng544jNzdB2vGJ9lm6a6s5XnqC85rmpVkn/2KHK1nj2dRlnzMkwqMgvuZuF2VXNuczHdk9FdOV3q
jT92VE6d+VgRHsJqA/Lu95dRDVVVbOmqCos8Kmw2sBdsFNdywWCk1YPDbDN5FexmQVB/4fWMK3Sa
XW3ab/VGSRJ7f0KUu8yD95tF86gFPrwYZAkBBAjiYRA4miRlgj/dtUvnnf4IXsb8Z7STPzpv3adG
kuKxg+qCnE/YiVa3EKaPoFH8bxA9eqERou8R+zEQZZLwmEc3cKeApuvQWs2OYu/Ex0aE6dpGKfBk
w5tSzP+h9s/2e+yDQbS5y71zymqb4MuL2oUhsWAUZESDqcY8QfKYPj+bySfzkw3cF+jw3mTXnWVY
pqqCRqpnhDhol4zyUv3nbzEMmYNs0GFxAgORSzJJfr2VtZKNtUZbLWqVl4VLWwnQtmgTL2pRAOu5
mvNj7gCaLKaAzE0ycFoUwOJiynW6SkZH74AWKAXXJDd5KaOO02eRKSkGroROGsNsCayeUVS7rah9
ULkD1LmN9KmpTCp56oSBy3QbgTeXfCTF5pqKNrKtprbRTC+A+gVYv+HRCnCY5BBu86IWgK0iNxtX
kBdkrUNucLJlTHUFw9BI8RmEvPVZyD9aCtAkShK16oMHyFI9ZzxLW2paG64rrhVcyszJPp0Wz6d+
O317/NZlSu5Rxx8A3uRwbwY4BLbvRE39p2vbRopE2vgBdsnEZtDw7ib+FN7A4IFKCYNaolegHyR8
6Q/sl7vdv9ltVWdaqeLK3GKVIs2e5+iyt/UOn5iAL0BfGJgGt1DBSEHhPOJff2BxiFhhUixMAgvh
WJpMx+TldYsRddBkAck2KTxuxihbZJGXaFm2hfcB0hd7zDIZkF6RvcTJ5JSK0elD/BbDiH8BEkiP
1QplbmRzdHJlYW0NZW5kb2JqDTc0IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J
bWFnZSAvV2lkdGggMSAvSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgMSANL0ltYWdlTWFzayB0
cnVlIC9MZW5ndGggNSAvRmlsdGVyIC9DQ0lUVEZheERlY29kZSAvRGVjb2RlUGFybXMgPDwgL0sg
LTEgL0NvbHVtbnMgMSA+PiA+PiANc3RyZWFtDQpQAQAQCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9i
ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjkgMCBSIA0vUmVzb3VyY2VzIDIgMCBSIA0vQ29u
dGVudHMgMyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYx
MiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvRjMgMzcgMCBSIC9GNCA0NiAwIFIgL0Y3IDEwIDAgUiAvRjgg
MTEgMCBSIC9GOSAxMiAwIFIgL0YxMCAxMyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA2OSAw
IFIgPj4gDT4+IA1lbmRvYmoNMyAwIG9iag08PCAvTGVuZ3RoIDU1MjggL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSImUV0tz48YRvuueO49AaoXFPAHklpTjxLlatg/eHEASImlTIMPH
apX7/gJv5femv+6eAUTLTqVUJXAe/e7+uucvD3fvv/YLs3h4vDN11dWdWdT0l34bZ6omLhpjq65d
PDzd1YvN3fu/fWsWm/NdXdV1aBYPK9p9eL77sfimNL5qi7G8t8HSj8u2NKayxUAbxKgrviubqim+
5/+fadPbyhWnfi3XdrRTheJAH1vjoDSVL/pRTjdDSVqZ4h0dxyj3cGspx+fS06HeEcqPZWPoXi/3
LruDcur3kABRKjjd6JPk/pRVvir7a6Ldv+AICqiwT2WgxVHORbKenM/6Y508ouvd5BnVl3xRVzFp
ci7/+fAP8uo93Ql+8fDV3T0728DZP9LxfSQP0mViYoqn8r4h3seyJtFkm3HEYgCnBletxeWDXn6k
jTqQqA8F7VjSYZX4JNKdfpfMkHTrEAa9dFEq5b/+UBJDMsIWX66fYEZDlOthVB0Tr0vZkYpwnQ1w
sHKDerUXW+Bv1q8h7a7jKklKLJIFSC/T0Z25SRZEzyVdNMQL6UvhN9BAFb3xy7i5sWfLxr6fWIKh
2q40/yrvofuVbw7j6qVsLW2/mwXLWQSLYyWhOhAL10Bwf8YvBPncPx2hYij2Qwn++QQWQbbjxEWE
LLKjL60pnuFpF5DlX4T6Kh/yuuuQTB84S7G1Kh3ScEsnbZASMJOUFQs96N2xdCiFi8g6V5J7779u
BBWaqmtqAQX96SjEwS5i21WdpzWjAhlb/KF8+IkIWyGsq5bQg8jIIYWRo99BGhfaqiWmoWojWHLC
RyteZNPbRnPTk/YjjEHiUMxRwMguCjgSe9jrnYGDjOBeNPjbRLWUiM64abGgkCpK3bql7W9G9gWl
KNlibwOsEV4iZQSMAhCPKt2xizup5lCcB14h12OtKUd6AgIYGjmmDE4Fgwt5gnTZbXhn9wv+v+JH
EXMcL+9gLh+dTodTFqDwZd+Q1cQs60ar/nxm5OX0wQnDMVXmRS6uuUKL512y8fLagC9YASUpId9G
Lw1mAodWK9szODQAB+cCMpOLEFhKGx3pw8giZ4kE8Q8Gkcw7FDYf8OuHsomc9JRbrcBAlBpuFQZ8
WioMWIUBxzDgCtXvvR4yGjSCBgT7jAO+uBIE7F6zQ4k5UPaTCUyC/Xq2rwL0c2WhDONdYkXudhZu
SZqRV5wH7RL4J8DmuKn8LPqMBzH4+W08iuJ9jV8XkU8nbp5GQh2Ly6k/IQo1Fkc5OqFFUUbQP711
1kZqqFAEKpyUNQmsmxZyYx1FbqidiP3P38tQQ5DvLOm6oRVnpe3Y5FBbRna6P1uf+HbU2y+0wumf
VGoCkyTUuynVvEj9BmnSBSISLwaOLyeta9JCYggpiA2h5mf9MYwDx6/JR3BOQGNYH3SHgtZyy5Fl
4jWWOqoAtVKn8sUSCFMkrh/LWOfO6rOKiUciEl7pFiWwi4C59S1djxM3Y6hi1Ngrs2EFrrccWV76
ZiOHT0gsyoTEiInFBDSUdXJu4vQbY4vX1BuoFBuMDmNJMMMxQUZLb7aKBzaVhdSkEVh2BNM2n49S
GwRG8L7nOHb5dEXdkj7bdCmx2WoVWg1sSzQIbJ1sRikedANNmLoJpUqvOzO2Acn/ljUGbhJtEhmU
J0C3eSMrP7sREyRYLnPk/CqZk64lMwa4vW6ggRqhn6S6LqspGL5uEwzYTisDbXMUxCQVDk/kHO+A
96uykQENoxS1rkbw0LtWGmbgae7eWzTWZzjFYJZoJZNwusZtdJ2lZhR4B7Td45TazP2s/JZz8qwJ
pIhHvHcyJctwDZVeq5kVUpotM1TuWfufdWPk06zm4RG/MFGu+UCZKqs+icc45hl/XS1Y4F3D+uJ/
Jaw3v9/7pm415l+Ug54mRDvvbb51M+iXpgS/RHlESO8atLukHgaNWox2R75/04PSMrWZxDxxwYzl
g52635UzHr68VSexuiSKqZGTKX4m+3/3OQQntngsJu6ws/UT1a3iyQ1TbwWf4/3bba8Vx3Mbg0L6
xQwliWygLj8OKYWQJY8lvzZOTwhwTGMX2+JDw63ZGI6HcCyRFCtZ4PlHCL7kUmzSFWRawPoRzwEf
McR9V4LV9/z/swg49cqZG62XxBd6I1r2lGVNh4n1YZv2wJBfbZzmgeGRjw7CNV9QM/ZUs8hxRrOX
MjAC3SYtD9/quqOg/6GUcAW2OWi+oqmVHLd9qk6CwZaRtJYgOXqbBdhgxWlmYnDqE3Emw1TJ485V
vhtdo5c6aTJMOsr2Svhl8t1FQB5p5hlkrZWHp7OOe6LlnJlpcX2lP+hp+HfJulGGUM7+mmtR7VCB
+0NyCUlA1gJNHD1yCSxFhVf+O116Sj3PqfdWvjY6uYh9HSWjZ2jnfg5+jSYrn1apVL6V9U6RQVbs
G4YLF4GNH0v0qx30bcVq5DaPALt/y90kdgMbWkoNvcY6dxLqLt/SzyC06EstgHKtrC8A0iDvWkiB
Y3zDyJo9mXWG/7x0fQsHv7Cy7DszmUC5i4Q9qFr7tUTHQCXW8GNJvdWqwL2uht8AZXU1gxd3Q/RV
xVPBlZhQViGNxy9GxZUc85Am0ETtba+sMDk5M2G65SEuCKJFhTpTKOcrnymPJLbklxheeR0GzPVw
5LE/5AvrYbrjIhJNOaC5UhMekjKvVRDj3oFvxw4VhSXrqVUT37WMOEEVOya/qPZDUj99s4DN2ymt
TwCp7JaBCqHW4m04Bx0XY5MiTe6W9W4tRNj3tZRlzanHgbecS7bYTreYWjIUcLDr94IIXZFZ6VTJ
/DeZ01GOT+Q/W/MgJPPW/Lr8R68P4PhD2XaTUJRnBOI4zl9SGBmpquk2Z6SZzBH1D1IoeGK6JBDV
aqRaG4E1omyzF3+d05zSXcJsfQHwfLOU1Z7bETdgZ6PM25bHIcYyyUtxZkZyINeY1kzdnwQbqJ6v
cnDR7ylTXJTFQU82ur55MNJQT4lgFzX9pd8tzVYL9FlH7eeJjfJaqBap6zE/fiWtrAdXFEDNM1tX
U3wiFDqV0OJaNhzGewcVG3ZvehAx4rx+R1JA686IMvpblPGEPBHKzFHjryiGQFEy8CTV4r2lLhty
UWy5dgQerrPKo2nKemg9VZ71GPjXwyoVEpegbcOMHZLSmVSC12NCAxGgQAK0aKLcpt0xIcALZDQy
y9rgMpflrKIpiTLhI+53vzIGqkak+GvhykQ/yYZlxsJkoF7IOLa6gcEMsDagoT4CzW4MVISTm4lc
+b5LhNmxt2Akj1FFozPm9U5fVV4fj0GfokFwno1OgFhL05SmJEt+fppMm3htpUB4cpUq5ydZ1Kec
m13k2QUFZWDC6qAXYCdqGOOaMh8oBKb4JO/UkFktb+y4kbRiKn2aeuErL0w801g6LPV2xnLk/fXM
CGH1lnYTjeVES67Ao0ZMV/2GrIg3MtoyHUYCF2WmnrFL1vQcw4c/auWZHLqYnyP6vvFcZL5Ypd2r
bg96mzA71nio/VmfjDQ61VaetEafAq6N6c0ysZfnB1XTGn2rrWdH3GnRnHtAY0d11oLjO7BGunIm
Ctg3mNx+GeHVLuQRwHJl+Swj6/D6GAy6yE8Tyv+Yr/MM0rxBlYzOhOuZhGSVI4Ax/78zxQWr7Jbx
kFm/1ZEaDdogWI1eb7iN0jNpjyZZTxs81UVpxFFmP0qVk4z06ZQHvSijaNRGHwv9qBS42TREvJZt
GUXrKOOmCKS11eaxTcTcBwM3cg5KRAP/idv6gRU/AZeR6fudXNpd9O1og4y4fBcV/V/Kq2W3kSMJ
wtf5ijmyAUvTXVX9+gAb9mGxhx1gL75QZGvUNtXUNMl57D/YMDD+4M2IzKwmKcnYvYjqqqzMrKx8
RJToRcdFdegbgil1aD6OG/XVrrVb50Mao6eLYOxcPKP/S9p21uGiRVyyr7bsI68FXoTLn0Y+GEsz
WQEYXwQ0mZSxNUi2WhFurzePoi8J1QA3lceRjiIX22R1A2HcZ3SozgJdGbqgviOLG9npaMcsnKjR
t/VrRqYn0+mwobdJXd32dW2wwf7npKbhDBvazmFDJ2pvFTdW8KpqVv+QaDJ50OPHxzUi2kqUD4IQ
2E1j1BiwH+2pYi7grcse/0f4EKOwyeRO1Y069e9RUuMmEUUqWuJLpRrMomKyM99moC7kfNTiTUQF
j4ADQfNbT4rQDn2nwxz5jG7cub78JTKzra3v9ODOvo+iUNDXlcYDXZnHOz4NkW5q0+qQhe+RtKnB
W9o5VpptFvB53su4SBFYtsITJMC4C1Pjd0gDMzkXlkpnl7YZwOndZc4WRcOkz3M4zieDtkPRk+pw
wh0V36LW+2CjjLuU3erPO1Zrj7B+05WdKsdtS0zA+wJa9vPj+njAGOEofV8AFlE+C/JZCOB8o9cJ
HvteMQb0Pj5dmYHQi45LravM3h0XphHZ1yEsXKIxCmpmUN26qBJb7fIt3zf2rXWkC6efWKcCC3JM
zYUX+UW1cLmSjRWzTX63+m0/o87YSb8+6Pzr/Ru+1WwUfWIXCOyZCC/wATrwnQEAFd3w71or+HHQ
cceFC717/zbzh8PJDUrc0qICZloUvppm523xbuu886Qn5wI4b/9hXj8+jmfXqQPLAW59Z22SY6pO
2IYNrVAXynp/Wck67LzYuo1bOHQ2GE8sVRnqPShiaq6xOUZprEkeMsKGJzIat3o9x9KTUsl69aNN
958LQP/3QI6dtHfb/ZYBvAHsXwqzqO1YLAhdW9Lj5pyq/bTXaUUE1KonFchSq6lX6kSBwe/1OVu8
eah8kzYdWkt3gRMppGXHKJAhydq1oUWWNr3a883YoQMMX1yjqVGk2WRDDHaXmBuXCljgmEoOU+t8
2HTlmyy3BvqSiA8DSUSq2nxm73bcsul+2tn3YAsY23G519rPmdFn98fb3CyPc55dRn32Npnvdcp1
q99tQSx2hocFwheYxv7FrbXJ7WzRN+lKbxmZVn8A7LS30dc1H7vM+JKizOZcX0zRYo56s3UTu7B9
VGKWsrWH852Elc8Y0H3WcuJF3Oet5vfzy/jvHlWON5RLYCzpcbvKoMVtjh0c67gve+U3cQni0ym7
NblDKMAaAbmKm3s0bdeXAcg+b8/uakdexNzBpuSErKkh/6CgBV1fwGAixgwKLlv/MYzZGMaUPIsE
dJE498EXAHxrA96CHvVzzSmHsIWagYD6+bdCiVcXpa+ouB0zS9kfd3BEnfNqy3/nzguGT889CI0D
adZR7NF75kFtfBQnbG/0NdVgH2QUUpnAT9Jnf36lN1tQt9oPO2Vfnb6R10LSLmbFX6Pl+IblQVx9
sxOmRp8yvtJVYbkxzPiecWCLDLGSO0TMukkXR/1cA8JqZ+o7VhR6pgxX3S1KnRwhlOazpnGILdIv
JAzdI+Ky+lI06nVI5EnrOzW000PmxDdbtM/PzJMQeoO12GPMXR7vvtrvTrqlXtkN4Lc8QWhq+iQm
97Pf7gOiCgylyrBLetjzDVXrEe8hlxIE1Cl1yM5+/ZuumNpMl6ISVBQYR5VNI+0Rwcs/ckiwSWgz
7ziDu9U7W73Xxo1n9hMfT8O0+eoCrmagiCv7irujmwAjUO20tq1HZ0M3ClyFhGLU+8nBNI3m5kbl
/LR7778wlNB4/rSFl6+eL/38un+C7wJpnV91vzgb2kobXmWUMLTB8AckJkCJ0Nai6lPRkDZcuXpi
QLXSomSFUYCLQvzr9AU1hsBsh8mqaam2XkMKUARU3JR54PgwSKuT1/L3OoFSlsD0i9542//L1nDR
F+xnb3ova/8W1Aih+gHfbba+KQJ+Htx8VlJBM5CzIAk3P7mUd5KHwgB+jOVZg3Hld0WZx15axK7a
0ZXDCFSsks5NzLjgB1wtc7RX/ELFrze0FHND65WnIvhwucNlZzKyEh0W3+gWPcGXNmu2UdJa5BQh
O2fcZMo6jpeOdYa/h8N6xuMkuCfcFV69+7Eq3wqXuX9TSbcJZXpb0jn4JYj+/a8i0amAnGrLSvbL
t/ZvEJJRN2+rXnwWPvr4RigtTyRTKRCh7PWI/x8EfvZyputvI45o6zE2tdH0ryz9o7iPJzrtzl6u
zGA1WJ1HqyfBl3wcQM6siRgDKY955ByorjjsbYGIMaGEnUVmVI4Ry8cdtkhRuW8UttAiRc/kYoUJ
8cm9OYAIcdTK6o11XJlBTfcKzVFC4zRjtN//KGvRTSc5vrkwGAHDMgNOTM+4csqzd47U6JVLQ2nR
ryiH3eDXgpTASj9cESq3mE9v9hfunijFpG8XSmVCJ5fa+sbdwskAC4DpSu8OVmyrp0zctvpYBoiv
xABwqjrXe2aArtmEh494D3HUb+LrGhXz3DmiFpNrtAC+XsF1vUCSSoFZJ+fuiwissT4SDOorwrfd
Ya9cCFdBBg8FZvfHoiY+r/jAAGizbhwIxbDA8u6JFYAFsqBgPjQjniXiww1/V2vmExStt8v/avkP
oMpOH5iEDwLZb+DeSplc3zHE5BrSa6Lmvl5ip76Ys9AIlLVc+2gu/A0XSxpAzQviBKKcCsWjLyav
MuX/PmjXTdaXWbbIAmcPNbOATxHLXmCZt5OohaB3Cuign5EHMlxcN4aNjxreps063RhTh8kSumX3
gbND8vYB2VNhAip0u2lXi/KbykZEIs+jC6d8MdfFDmb53p/bBQl7bpIUD7OnQvYKYml0lF3defKI
LkEidOqtUNUnyp8YMVBNdk985Ii5/9P2ZbplbVwBr7Zapthf+n3SHyCIEmBn62IVSnzSL4G0SEpJ
uEAoQcmNihheVtrCgY+oIDyBE49CqoCoOPmanT8WpcHi3ncIjPFkPWAcmrzA68ooxtkVXtK6243m
NLKybPhgFctfoqvhLlfXmuwKdnJU+0dwj67MhnBwXrRX2otiGZyt8FtP2OXm8Tjav2se2DFL5R/B
0aUS0mi1+JzUnY8i0SBd2ZIPly6RNymWOU8bJqCGynO4zXtoBGKMLsL+iQ09ZIWsoi6LD3qfLVpd
KY1AHz6x0/xLbH/VeTo9PbgCPwn4zH/k3doKbfyf00DyelstV9le++ffrk6yPEujNDtoehjOYwGQ
kBK83tlhV4LDORYbvcqiOIRs1dWdH0SkynhbnYf1pcqqO3uew3FmZ8YQfMRzl9LB1nC6ReXvpY0K
H2lXvw66ZRJHdTCu7CzHkUBVk7IpkzhGgGBsHU8SOo1USTLAbSSWCOORqsAWDNAKsJoqTIVxq3Km
ZSoi9o/jN112rzlkJNqJYIxbZh8TisVGLmTG3SmOmSgvQXoo0mO+3cghCWY2The2zGNTf+levuSo
QtPLFZJafYLBaSG5HslO0nEBhrZRsjtMClxCpnqAibFfPayX757Yp9MWXDIIAX0s63xyFugCzjuZ
9xV5E3z94f2b/w4AGkwF3gplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBlIC9QYWdl
IA0vUGFyZW50IDI5IDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0NvbnRlbnRzIDYgMCBSIA0vTWVk
aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg
MCANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg
PDwgL0YzIDM3IDAgUiAvRjQgNDYgMCBSIC9GNSA1NiAwIFIgL0Y5IDEyIDAgUiA+PiANL0V4dEdT
dGF0ZSA8PCAvR1MxIDY5IDAgUiA+PiANPj4gDWVuZG9iag02IDAgb2JqDTw8IC9MZW5ndGggNDgw
NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaxXyXIbyRENX/kVOHY7CKi7qnrz
cUKjsXxxjAnbh5EPINAkaIEATAFaTv4I+YOdL5fq6gap0UGhCIFdlZWV68tXPy2vXr0Js3K2vLsq
i0VXdOWsoH/2d9csQpg1pVt07Wz5eFXM7q9e/XJTzu4/XM2LRVFUfrZc0/Ly09Vv2T/zeVku6uyB
fv2iyk706xYh2+ZzX5WLNlkoFi6KfcB2u+iyu3zekNSB1fjsKZ93pO0xn7fZStdIgw9Qkdzh65As
RG3HfO7KRB1t1LSsPyZ+u9M/epwjP6ORB2j2dPDI1qo1h5xi02Qf83lFh0zLJp6+XY2vM4k1CTSB
FjZT3yF1NCtWov4LSfuKv0Xbnk9toMSTTxwTGAj7RGNPKnzb0Jmv5oH92mX7e3NJI33er+f5v5Z/
uZqXi6p2M/pxVZgtX2tykdvfVE2papwElC1S+7Kd7pjEKe/IqS956+iSRT4PTUWrP8GrquF90bhl
Hb2Eps4+5XyaYlDa4Wvk26dH7A7Nc52lC76mhSgaFbO7lRrOifQIYUORFge0rMqJZZPNGykpsnjN
+R8cppsKdoBSALMlOAc4grW6QLA513XWR8vtMqm0qGx/PGtVj640abXfIo/0FZw574bMOUndz7iy
YXN81vPJKrvnmnIoMheowbPXWmRiQJCitG7VPqzi7u3ZNmzloAr39NshqO8ylbhRA+yGdznd6bGz
WekhU2bfKJeiI61vIdouSi6LeMd5p5duEJjOMmgNOnh37uGeS/zYchSSe8USWyCvnYPftOAqJOJ2
dED1R7W3nJkm8Z6DDDWhlR5tIgCEbG9/POYlMntmcRW6xpUVbeJuD23/yEso+Svnd/lHyuUkK2bW
fjMxECDhEBg9IG7H+PFXEkSRXQ9eOCc4O7olemEHkjB6l6rsk3iqvSIwToMCZivZZdhrCVVL7pCo
a38/qZLtK1343/kzaWCp49RIDYQaAAihRIUhYmxAdP0cM2OXKJK0ideFgeaQb71FMzgt54veWHAm
X73pdNqWi66iNuVpq3+3xSLMaoK7MvCwpUZua2lkl3fojIIKx0FjCfT5JcdE6vc59xa1dw2wx6Tx
gSy7wzrQpctk6zF3JL/KdXCKPd+Y/mIP1UNl5tSlmLPc5jzp0QxNxVFgZ5966R1AJ2y9FbEPOew5
Pa3WyDMPbRe8yuxFBv1cYVrd9yK0tyv46wl+ieqNbKxOaBYaZ13Uf5Ydu0U/n1QFOrNSJHN8sd54
I3IEtSQX7EbV8jGv0MW6SGjuWk9VsBMdvQk5FIHZmoN3rO57aWYaBPGq0/OBe1BnHx5Xu7m1vCC5
RlzqSWlFwxGsgg1jONMDQ5omlp5n/0IZ54zjgQjsakwLjy0aD8Ono6nTDAdWql3B0iWqMD3qOIhs
LoVseoedMKt2w6/jur01BWOjNpLcevDQ3AEsh8HLfR9FN7yTGM03K57zKG4jIvvBF5kkNbc5dyxS
U5oh6pf+HMbe6tBosokT+iMUrczWdufUNrJ9GOCX1IstbhNeZeyECXX1DJGq3IRIMaa2hqnOMHWk
y0UgaxS/MyUr51wKmimHshwTlC8eGIMleo6wqqKYumwpHkwMlDvOYsk39a1Gxk4oaKR8h9TTJ6x2
McEX0dH7It3iXfvi6eyz8yOkMR6+gzs+S8FCmzQuX0JTlpOQnTf9nxR9K0XfRejqGSGKlxoocDb7
b778d4LQi6LEvMA2oFhL5M95y84BtLMVYaOzD8TBgeYDXRw5gurldAJ0CKBODwxMnXBo5ok0UpkA
SUngyBlndztw9wIya1EumkTRkUUeVvvc8xD1Bdjtm7c5Tak6W96I1m1i2oWdoSM9z1hoyh6Q6sJz
geEVxVYd5T9CbZo8J9XGmhfj8M4ldhTfItTfEd8R8i4FNbYMDn2Ccm0dq4hx2TXF0PnnozD3eooY
gNKuXTgprNG2ayI/FKIWIlpOUfQ42o3AzazIdeUlLOvPSoL0Bc+XxOh0ZDCS9nZ8nbuSSRv5W/Eo
Z/fMOXuWOLtAzH6U9yVGUteNRhJ212b3eRM37iHaMGUYhy1FabYAPj6PmY0kbNMDGIZJ2PF7lN87
gUrYuBqVOw2OULZiPBURB8fLKw5Eg6MZ3EgDyACcd/LqKyWKuIwgr24g+7dBTyiqsR6z6AP2OAR6
uo+2iMMtAhAKwMx2sHenx3sId8PdZ0oT8ridKtnahcqkuT59OxQILwRXyTtvFAQgwPUL70svodbZ
7aVMyuw9AmRvMH05WirJSg647+SNxUsoCIdZH2pwJvnsyfrAdGk1VqQ/bGIj2WBaF0IdYwviqJfc
LCFfZm9vTP8L175ltPn7z6Kpzb7uVFXP5c7Uu+VUqkYwqVA72pHc1hgRUnepJScm6Ki7UDEn/qY3
rZsEPK3tCQ28k/qppyhCIb5G8HzSdJzgkHAUaz+mCeUlJvi2SIibnXqP8TpwRhLrqoRcolxdlzRw
L7XYjOinrBwVLMxChYsJZGm//i6UtWCb8NqnwgI13FWNMY7E9x2Up/R1ve4H7ibxsqAeB48SQjil
cubMYWTAh4sGAkDdJQQCWG8PXsy74CLeszLPPGr6Rn15wtXtd084qak36oAxRFS0b3CpVXR9wUDt
W0mbFg2eXvwtzAg10qAPpCQqKwmK5GcUm9NC8NpntbFH1bqRGsN55oRfzC5VLz9m9hdRObVwHaV8
XdnYrahR1i+QylzfiuKQbd4JbIbIhf8j151NYMyRNyDAbTUlwCY8xEusm19UCVM8HWjgOew1qu9W
Ph52D6ecqxIPsUaftaWa7sCR9iJ5UBIlVI4vl9cNV+lGyDKTL46BVrgvKibj2tsOPfZJlqnkD8IQ
qXvWouakulfMFMWeJ71ihTvKJt6hoqrbFICLqnlqv0g/HUDFi5B9le2dar2G4SUXB6+rVjjr0XhP
q9NWlvRAdIqs/ybGfgeDQ5O6EbDhadH8LjtKUMgzr1Lks3eiPGDxVvMBWPLVzk9BBuPcB6jS91ys
Y9rrJQYjWod01dnNYNlHgXsTUWz7JGT3h6CLhvMmWrGGYR0CJH5OERTvjrZKPGGW5Ljoi2Rc7Pc9
TznG7/EQ+zgaUruxczFSCacEQNV0rC6eGZBCZvtoxnoYLjr9kmEnnulVnyW6QtOHN0PyQNAfXdyY
wjRlvKADPuLVS4MmLa22EYrQXBbv4zeRZhWb71POP9o7O2gt0NTvbGclmPAxd/r+tMANX9rQ96et
vG1ahbBJh7+MBwobB4AvUdQ2gp9cEwXw8BwUPeaOEwNUs95/l/+Qklba+5pjOtBTyQx/+xqp+fVs
W8YkLyihrxoOpx41lb/mmHTvcmgKsebJ17uIFCmHJPxoL8ywMyYrbPdaQKUSag8OqzXWcpk6U8kV
2WVKZfVrn7sBhgLrapvELaS0avmhJBKR3KoJqu444cDPq7egxTCtB1dYkNuc6ky12DnVtpG2buP6
4RkSthK+6s3RJIdy02Zi6saixTEXxPZEkcxY5d1DTO7kYTWYsZXXjZCgTrhSl73gmmzq3ZN3xXBE
TUrSELizBOeHclEFEz238Z2DxytTrbfx7ZXqLPDUOVtJxFfcxLG9kO1W+Jq7fPgYx46GDNX87EQO
tfTbo7xyOSZSJSU/djV83nF6tGoRgEEIz5IiUkvHs5VsbnU2lzolsUKRb1IJppvgbl9ZtS3bMRRf
KIJ6ATJ3ZjkEsGh0yHXse6E1WsqMEYNo5pTKZbFv6s999MG2/kC/mCaDyb2+a0oJdSdvpYKOq5uS
f2IHa/Pu6/paMttGh/cqbFqfZPifLdx70X266J7RfN/0k/fRfiMnhSm1dfKGlFFlI2ny7LOpO6Ek
Oih/BH4HxW+mQUVSBEF8rzXkDNvgeHgnSLSqzCQBdWQfwUw8w9Fj6iTUwLVMdsnu1hQfVDHIbMkd
4YNexNrtFppwAsWpNfoJZt0V2v+FjHjvccn7/eHCiP+zXiVLbttA9J4vIQ8ei1hIwHcnlVSSS6Yq
Z1rijFTWFopy2fkOf3D69QJSGvmWk0QsjW6g+/V7q5aTlTPoWwn4AmKSpRk4Lc0Vw535vTbr9Ihe
AKlTrE1SR1EhxC1cObLf5W4+2XnqALM0gg7KjPtKZ/6hDwPK3kjbxtMfapAz5G2KXEp8GYMh98tV
VrPmCN5z/QdQdxk/2w9cJBUzTmp3IxMEesl3tOvPOjGfgvmpmDdnelR0QDQ2skOJ+ijOsMV9b7bL
FJMUtDaquhXfDVw7HYp9JlJRiJSvSggQV4DXbnEbZKJ5sONxXbqFjEmKBF3RItrPDJQdMhBMOjBe
+TJsq3uBM6OdwfpBMjvD2f6gXpOdq19H8dWsDZsPNE32QvX9yiSZyUTwTcEFzv7gkHO8JKwwR5ii
hs0PMKmOLiEB/dG/Ol94lC/H/2CTWpXqlglxsERnEwxS1FD3+l32ruUEc/rIt/fuB9JSnuRoj2AS
x8l2dhOVbIJCL7Nlf7NUj+PqIULU2M14yjPFVj4+Mkfhed0BaBJGkSolKs4UY2WuQAWtuoJ1vjx+
I2/ZGnV0Ai+pul9WLHAm+Pmo/uagYSM6NBYDfLmdXa4r42uJ/nb72ytz2ZlCUlIED7zPJeNAcx+Q
P4tUjVd6/dHATxlpK3eXlWg6uQ9zv6nmxRy/Jos2QjJW81OCpxiWZ36otlhQg7pPv/4XqSIZ94cy
tCunx/7u3exGzzezmnr06M57zexYDZoL5TFl1QbLIvJQOHp5Us1jGdS993lDNpxbWeBt2TSXiSZU
j0MUm0qS2eYt+6dlsClRULK50JQZpItrrRWVKG25/T6JsnHVr0fbP2f58h4GBN4xYZQD+LXBhSmG
bG/a2TmHugnkdCnv8U1Wch/UZ2PFG6ThsKs+gCGta06h04FbGjesyH1F+jFaRlmLHuUDKGJvoPBS
IxEaCRZNC1mPP9/llEbEE/1/LR90G0GPkEN1Rl2ZJLqRzR7YaYYJB149bZnlFN+KRycUV9RlKJ4m
VduFD72C2TwyAoK6KL3b6YKpRPZP3dLlshP9fjfJS3x7SDXwD1fcH0uI6G9czIy4Wxkf6iw9zmcE
318uJ2QQrVjzDAXlmBzIQtxUi4reqd2X03jop91JP9GgGmDnc7Gv3HijMXM0WaQKi1dcqlw1ay39
GsvGi46c7UdoNNEcNLEGCmIU58SCGbjAKbIRFf5YJT2kEqHTu2Ls6gQURRjFtkgiioU5YsO4D1pp
9DALQ0WRUOuTylEt6otRlDPaOC6Pbik20CAfRZlwTYnSSybMFsfCDzdbFPhwhdULReH8b5Fp6zkO
zhun5SgV1gXlRtXwqutuXNwMG9tm49o2vDYCMlxcshFcQMxFZCWL5c51uy8GjSANkUPU+ekxrzBB
M3w1Hg8Dtl3ACiwhv5UMJme2TNyNzhcCvz7dGFQ6b4N3IsBsDdLfs83fiatrUVvXpcoZ6EYabXoU
VQ4tep1/QGmf8Q5bJlrgxK0r6pFSxRjcdUlso5fjmZ8uJpjKGcX7V5jcPfO16ZnhUVV1XC0y8AJd
gAHbsS1ebR7R6NgYhUhlXH27clBzDOYyKjks15vdzyAm7YJz3y6bPXmRNrTg1tqc4Hp+Gwsc7fzs
6AD1U1L6ZulvPRAlEUlqheHwCxIet+6+rymQEDh64BLEErBqpJaEelrLp44ie1aMiQSejiHyXcie
gYwX7PtLHXlhXO6KgiA5gA7+XackKRkYwEddtt/pn2J0K4foMIurDjGB6LGy7JheHm39VDaoafXq
pN7eBnOWwakEtbk5TrzWLePuE54nVbOLkdBTCDf5ABc6gMgvyo8PNThn0Ku/b3WttrpBnol7dVc9
9XuQnAy7Tc4B/yN4EavNbKtxlkvsxHL4sns9ysBOf1+lLFqzX8yoblzLRuYcCX0U65FgunCnlsd+
XNfe8YN4QNC3OgdhZG3CvT/XjtleMe+ytM+Fe1O/2+tf4S5zACfG+tb8ucrogXptN8fMB0/St8n/
VomUONxPj9tkbOSet0gdk5Ku/IJdh+oDo4mv3mubtl8uM+PLVNDrL8BOQx8Vsp0oL6YRPKq77Aj9
XMta2/p0a2JztTM3J3QB5J2N2JbjZvgq59vmu6C4QSWFUF8p+5/dBWtOsegEZ/rr/c9ehArob3Kd
SBXcXspye5dz7ZEhX54uZ9071FzyOL1pRQ00DJaokYPaVQFEfCQ6N5ttxeoZzwwNsKo4uwIhJ5dQ
Lxw3INBAzc1Vv9cN6xUHibmidSTqHOOdR/0LY6fonqIP+a7UOk0BwQbg8k3QRGJ8WqizRvv2X2fm
lIEpCzrmyO/RVde76Agk8jK6GzyNiqdB8DQqnjL4OWaUBNQVo1PksvBZ1ADrM4LEPRFyjxRzyRlQ
NIKLkZt6gz6936mJz3UrPce7QONiaGQyf4IGWKGkprJdKYCTOmv4yhHcx+ef/hsAm/FqagplbmRz
dHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI5IDAgUiANL1Jl
c291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd
IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04IDAgb2Jq
DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YzIDM3IDAgUiAvRjQgNDYg
MCBSIC9GOSAxMiAwIFIgL0YxMSAxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA2OSAwIFIg
Pj4gDT4+IA1lbmRvYmoNOSAwIG9iag08PCAvTGVuZ3RoIDMyNDQgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSImUV0tv48gRRnL0r/CRBCwN2d18HZNMvPFeFom1yWE2B1qSJWJkSkNJ
M/CP2Bwy+4NTXz1aFG0EWBiw2N3V9eh6ffXnxc2H++Y2v1083+T5vCkKd5vRn33X2TzcVrmbN/Xt
4uUmu93cfPjhMb/dHG9m2TzL6OKSdhffbj4lbp7OmnmV+HSW5y7M6+Qjfc2bZN//V05O6ayY58kx
/ffiR5IbVG42b7ImF7n6zXLLxs19gFyWVQQI+5Q89OnMlZ4YEz9SrUi2aUZs17QdfNJC/DwkSzs9
286OCOijTDra8PT7ks5qunjg6zvdJDa5nfB3nzpH38bOuNnamO11H9rlDczWjWfacNVYXdV0NWVF
a+excUxnVdwd5PHOrOXFKt1eH5l98i2l7doe4eoONApwhKk6sWhvYqN8JTi/pDne+Qkm0S8/B7F2
RU7M39gn76ii37jBhC/B5OIShEJ2S3HivLtdfLxhTzfi6e6YhrlP5P855RvrlGIEezNXQ4u2l/0V
bVSB+B9kPeyf0uh1uqD3XlI/d8qR4tU3NX084G4OM4mmNNJdpx9fUzKv4qetCoTx1lTRDWG6F64n
RGdB604EvxyU7X44kbLei8PJS0QzmKz2NDKs0GTJwRXsgnqL1lPZz+1SLka5pl4bd0Qx4gT/vOBq
4enqj/BuTb5g535NK37PkUeQceKRslaPkAFs5BoySP9nZg0dsNRdsiFUNbEm8lkIsOYR4enJORK0
Qqe3vqYlklI3v1GRyCg55EI3XNOeYAS91ytEVPCznosiphadUnQURk6mhxIHB+E6dC8p3hQxCXd0
5OJacj8UGSmu0tsUi1Nr1094qip5ZYWvbTmmeOk7KA+1EJbgoIyw7xra5xfhhz6MRQynTg08y/ZO
NGuHuzcZIsUwF4dIImnWBftpERIN6Un1lkMqlHXM2BwZGxoUwoPSS24iO2YV3KZLSV0X11/TvNSS
g1/Kn7rB/gLVskm2RgeBTTavIoN1v6K9gr4ve/BJ5UmbX1WrJXxVRYtUyAm8ypESeMAaheRCYPz4
Xr/+D64UscA5LrhFVo6YP9GrhymH+HiqD0RTSXFxxwgnF0yzp3O0Nz65Xe1Z4Or95FJfSv3REldI
ppdIT9TirxRfjdSUnEoJlS6KWEt2jlxPXacwCi40JWtq/IY0J99qvShs9whOBZrPEHmsjCdTfJdV
n1rvFP682nDJp+j2HrsohPSAn0XXSDPzGfrDTq5qqePG5rOSc9u7kcF2b6RhqCSZc7hZuPFqe6Xp
C2wpubFDj/0bi7o/qvFnWe9Oc/YIlYrSTVMseHHLQrAAidIodKJUqNHl13+gHXpNjhaKOo4qmC/0
e/Ypdy9a7fT2CvEIhITOmknbLjLcoo5bKPFSHL81Wru85jdXKVEPXcshJWoVKQfoX15EfBvbs+6N
/Wr9vTfr+g2ytUT9tZ3UeY18aT8jzs9Io5pDHaYu16oLil7I5PU1i7RR5Yo2QiMdk/vj68EeI96H
b2YX54xSRn0jsYJ6zYXbiaNJF67ZOdo2mh/l+HCWEw4AWutSGjBR3SFjvYTtLHBugYVHid8JjjVh
G73bbtAvKBi9pmHNPTcEGNHBM77ggsVH+1SNl3NRaz/RsuU+IGWQ+xwanWcHc+9x3HsAWfGWLlHt
o/lyK4qmDi/1yzku3xXnH9XtqoJBC9W6O77fZILiMI6YSuucIWX+9SXqrLQRC/aGq2up/raVXYI9
RcUlGKCSkYynAi/p7RjLSzmj0ltIUygiL67YxeV4opmxIBEaYb4OdO2fKVWBPPkJ12JvMYnGu1/Z
l5qzYlXuzEou774m5bgPNpw73lK+FCDN9+OVNuXir/R2bNoKf1v1vEKxDCMd1s9oyfRKtu45vULm
ov7795uK+o5hBoCBgyzAHipiCngUvHDA+MxxGCJstnJnf5bf3QpltOK6GjTImuSzcaAz7XTeNVJY
cKvbbO0a5483YdeiEURZY0gp2PZ3WfXKSxicun1/rcqeVRmiEkM0CHZ0u07XDFsZd/uM26a2EaAO
7y8mtypwc8Xn/zSJwskz36eExm0IdDYkqYvAfy04vk4+MolP/o5hC/CBXAptUF5XEgyBCzAzolBy
DahovvMy3TmttThemcCDCVpjECq9OAQ43wmq4/ATIVwj1ujGjKCfjNlR6vgaKcclVfiYCB0jq3ds
ejK9TynqJWWlRXkYcXVO+GYMe2eG5xUGq7JfUPtDcjaCnbK5lvAKXaD8b1fcNtGSSecQj31KzqxN
w6+EaEUHdo7LKkWQJ4c9LpBoefLwKBFib+05QfF6uv2QYnj6+a9iHmZJB4f/i6lLepzeKA9c6Wp9
SJ+oDvojhhXJ004/1nfGy45EstLLiynULwkrZOJidVyDVn0Bqfz+rnEXeeclGgnjimv7UARyVMsf
+GaZ/O0fb98gmn+fAlf9lKIOPWqUcj2WEpBFxI4argKndcr8UVlgV1fgm6H02XYQr14GAAe7zjqs
rCcofDJGxGs0ZU72mfzMwBw11YUxYI8bqyn6R6h6bHyR8Uo4TPleZihEGeI1G49UW9XaZqntfnJ/
NZ5Q8L4FV2ad7GwSk6S6jDDbaM3Vq/5+qc7hXJ/YbDvwqYRzKeFWXc00lmajmczX3DtHI2XgCvzb
1attroc+yqaScdVDih7AXbaME97E2AEsUTOWk9FRFURc1/j4JbHxbK7amNgo717L0c90h/YfObvL
5JdUbyI162rk3qgcI5FGdbrEosu5uRDusHHMBlKAnvejS57s90WXr5qxVowaLi+mbp+400TaLaPu
BT+V8eD4LsIoKml9LzxnBR7KePQrGEMDedXSaJtSarR8MMClQY5HVKpTnX4wqnaMOriGM/RtgP4I
uOY8oXbtU2pdwSkOrGWmcZ6nH2bdySkBEK9Di2/QLIzPTkUoOaC/y7jO5jqzBUITHmNk0h5kU3+U
tVJuzCagfd8AUwsy52LPUPzYTVW+lnmM0qIN72PxUl5b5k008KUMUpXOaLVMfY47O6+5p+HDCDas
W8n9xOBoKVNcw2/prWyD2tjPMU3ApL+AMCTGft1eM3gjthUsWyrUzyUhXWRsv7o9QAEw4jDlcPRo
QyvWFlZ5xj5AQhrbYH42uSsDoCNxvnDCmS38cjbbLjZbT+ebnDb5+GU8I/doCQ8SgQcJag61VJqL
RfYiNkrEtxEbpjhyhNbFuX9KmaUvG5mfaMgBEs4t4jAIZQyZK4iliGEQPKzk8M4OHmB5zT0fsHcr
xwSWJckKCUYxvMYcJXSngaMz6BKaBJSRdtNyRpc2dAjKzzUDS8+jhUS+iBlOrSq8FI6Rbv8sb8dF
YkyhKqmCalEnm0q5Ic6wsallCuHMLmzwu1aqRlGmUYMhgkgYXt+HheyAWjwgMw8VViB/J9OIs7nB
S2GjLKPg3QohemxTcvjpWhEornebSH+Q42HPwelgdX4RIOTy/04mojAWgemmtjut8kIxdDLmnNBo
BBZXjQw6maZQVnGrlBu9/KquPJeFC3+l4snNUVerTL3+yrZhgxR3QOPKqD21qBKcGwvjokNlPfoS
A1W5brd7f3LVvtJKG0ILzJ0pIY9EKbrjMbIQnXKO5DJnsM1Uw/5JPtjGSPbCwSdu9Gidj0J1QIOs
jWopP4QYEYK6+Y2zC92tVU2izKip6EaRiQDpZPXMg2qrPE/7AY+X5Zx0bAlT79RIHnEj1PA2BdDP
s2Rjbbru5br8V5qpzVy1GlNIymHQ5W53J9lDqP3aFePxNhdfTHHHZ8Wftq/j0xgXMUhXnDqFmRf4
irSqpL6OkJtxMXzW28b3iPFUAIxymeAm83AVZ608OU/p7ADP6SsGbrnXmj+CSp8FfUnF/nDvb+kh
nv9XdtX0NAzD0Pt+Bcf1wGg+2iZ3BojTNBAcEIdK7RDSUhAbP4H/jf3s+DLtUnfOc+I+2y8ruh6F
SL2jpV99JmkZryLVODO4gMFJs7afD01CkeuAwxnUQk9jNcRjYhaJxdq+zU7w9Rn4gW5XQ1J8V8fF
m5NR+K67dE63ucldIoj6FZ0X/1vW/a6VzwSFtLDw7dY7Kl7whAXI+Tz/LJwN1X03d1FgqZEk7wUX
5NCeSTzqe06yyzmacT+WMpq1pSqgdJr90FhjJr4We79vHOs5OCYeQo98xEHklJcGH2ruTiitL7Vs
yQXGC4IdP0mMTeKrgU8WV8NsOC+RoDAocOBwocSyDutpEloqbTvVDXm9/OnDazP0OOY1pJ54HXXR
zEUTuHp3/EcU6nlDgRipdzVbXUNaLPBnVIuHaGYlA602mFeR+8D3LzS/gcjij9onnoSLuo/qZLvn
nGyfV/8PlYG5CmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3Vi
dHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMjEgDS9MYXN0Q2hhciAyMSANL1dpZHRocyBbIDgyNiBd
IA0vRW5jb2RpbmcgNDAgMCBSIA0vQmFzZUZvbnQgL0pPTEdERitDTVNZOCANL0ZvbnREZXNjcmlw
dG9yIDIzIDAgUiANPj4gDWVuZG9iag0xMSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBl
IC9UeXBlMSANL0ZpcnN0Q2hhciA0OSANL0xhc3RDaGFyIDUwIA0vV2lkdGhzIFsgNTMxIDUzMSBd
IA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9KT0xHRUErQ01SOCANL0Zv
bnREZXNjcmlwdG9yIDIxIDAgUiANPj4gDWVuZG9iag0xMiAwIG9iag08PCANL1R5cGUgL0ZvbnQg
DS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciA0NiANL0xhc3RDaGFyIDE0NiANL1dpZHRocyBb
IDMxMyAwIDAgNTYzIDU2MyA1NjMgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA4NjIg
MCAwIDg4NCAwIA0wIDAgMCAwIDEwNjcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCA1NDcgMCA1MDAgMCA1MTMgDTM0NCAwIDAgMzEzIDAgMCAzMTMgOTM4IDYyNSA1NjMgMCAw
IDQ1OSA0NDQgNDM4IDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMzEzIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZv
bnQgL0pPTEdGRitDTUJYMTIgDS9Gb250RGVzY3JpcHRvciAxOSAwIFIgDT4+IA1lbmRvYmoNMTMg
MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMSANL0xh
c3RDaGFyIDEgDS9XaWR0aHMgWyA2MjYgXSANL0VuY29kaW5nIDI1IDAgUiANL0Jhc2VGb250IC9K
T0xHR0srQ01NSTEwIA0vRm9udERlc2NyaXB0b3IgMTcgMCBSIA0vVG9Vbmljb2RlIDI2IDAgUiAN
Pj4gDWVuZG9iag0xNCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0Zp
cnN0Q2hhciA2OCANL0xhc3RDaGFyIDExNiANL1dpZHRocyBbIDc1NSAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgNjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTExIA0wIDAgMCA0NjAg
MCA0NjAgMCAzMDcgMCAwIDAgMCA1NjIgMCAwIDAgNDIyIDQwOSAzMzIgXSANL0VuY29kaW5nIC9X
aW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSk9MR01QK0NNVEkxMCANL0ZvbnREZXNjcmlwdG9y
IDE1IDAgUiANPj4gDWVuZG9iag0xNSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0v
QXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIwNCANL0ZsYWdzIDk2IA0vRm9udEJC
b3ggWyAtMTYzIC0yNTAgMTE0NiA5NjkgXSANL0ZvbnROYW1lIC9KT0xHTVArQ01USTEwIA0vSXRh
bGljQW5nbGUgLTE0LjAzOTk5IA0vU3RlbVYgNjggDS9TdGVtSCAzMSANL0NoYXJTZXQgKC9EL2Uv
cy9pL2cvbi9QL2EvdC9yKQ0vRm9udEZpbGUzIDE2IDAgUiANPj4gDWVuZG9iag0xNiAwIG9iag08
PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDE0NDEgL1N1YnR5cGUgL1R5cGUxQyA+PiAN
c3RyZWFtDQpIiZxUe0xTVxy+l9IiQroMvBh6yb04nYJON1gCQ+KmMkUR5B2DOrSUCgWECqWU1kLx
AqW9tJS29MGj9A7Ko2PKSx6iyFTUTCZqFjH4YLpkUbNkcyE5ZXcJK+ri/thfO7+/zjk5+b7f932/
A0OeHhAMw+y4xPjYhKQtMQlp+8M+WTnZ5EJh11pP7Gmc57KvhyvIN4COpLVBntI/v2KCkPfAjvf7
glhMP8gDhvfGxxQJy4sFObmi4JCY0OCwqKjI4F0n+cUCHrcwOIEryuWf5Ircm4Lg1CKegC8q3xa8
q6AgOGXlRUlwCr+EXyzmZ7/Fdq8PoTBoN7QX2gfFQYlQKpQGpUM+bp6QFySGPeAGeNFDywhlPPBM
87zF3L0M86+Hs5eUpHMJdsJL+54wwM4fEQFRQ8SiMgUpqTSSLTi4wQLJIBUIQClYv/0VjeD0DOv1
rYG0ObtIaR2pUsrx+YCzRn19H/or69F8Jr02qZBOjNiEpxz+khuNbmAVkFp9o7apvhFnL3t0paeR
TjDgAN+7QQN+ZoDb4A4CPmYBP4C+At4LsbdoGKen/gOERv8aYv6Ln4nU4gPD2sGh4bpBVG8m2yzV
ZFkyaTA2kJoGKw4CXWPIOaOe7EOfsu5OnjpQdjqUfwzPzs2QJKK0H4u9DC8HFSso11YKBtAsw1Xm
8kEarKRGx7FLdVX51YJaNTYiyW/JR2kGvZr+iN4YMb7n/rlR+8Uh/LCpX3wW7bd3OpvxtgHztIbT
RJDVlWp1aQ2WKpfEC9BTZJdVT7bou/EkO5JPJGxPQ48S13svOYF323n8Zuf4pWF0tPMQV6WuVdXg
bNdxBQWEFIh2k2HdAbUDDEAAGdJ7W2ubwOe/IWf0nPETgwc+oNdvpPeETUS8BGue/NasI0yEUq2u
IrCtu8KVUjROcW9woGlM34U3Ugj4bOQPbRM69LVQsI6OIvNWQGguZX7wgnKxKRXlN7UgnPVfBL9M
IeLIyowacZEg8CiPR55GKwpIkxBvN5jtrRzLGdup8gJ5Nq+/fGFx7oc5GwZgVxyzodkt8muhKkVE
oRLzf9kjF3YfR2lP2osOoddFXIi9PzkybDbjM8CKZNJxzHzi4I40NF01Z5roBd72C/h3naNjg+gN
YyThzgUc7nS+9gIEPvIDa65euMJ97O8CC2A9sqJsBak6rcQKCeGWZJSQ13c5LH2Wfpy6ZnfXqqYe
jcHGucLvPLFVQIfWVjWROku9xtqA9Rkdz6dRk6lWVKIorJbgigJFISGqyKt01yo5X6ko42R3ZF1+
0Qc2N2D+i7UuEdJZZpCLhWVFxe2Etb3b1oO5Ixse+ehNTFz+V9tuMoAUxCA6qtGuoyyTZH1rz6oO
69j9OXRUkylOOEb7yHl4haDujJhzrDtn4vm3IFT3rgMhIQxNRsXqZmtnk8PQgbdPDQPPac7jNOpw
1JFESQV2sVrQexzNKROdlOESXkWSivOmnXpKh91ts110og6yUCGrkyhl+E56iqmqUdfWcRSG0+3m
Vr1N76YLO3rFCju4M9/sJhy6wAAmMIxo68cA8hTVdZPydjxXUZdfy6kwShxtTuvg5ThT3t6cjFIZ
NqXItuX9L+xefY9Bs4JteSZWUNcegm2zl9xB3nYV+F1juAJcXki+khBWcRSN0o5Wh3lkPGtwP+2d
teXQ5zPy7hpstGqsKp2TL4zeUJqsm5RhkzryvIZjq7CIRUXSzIPTOffA5gHAHn+2oy3LiBU15hhG
OB322Ydd/VXZphXY+MgZt0OBThDTDgOfGwxgcW1AfmK1mkib+Qwpw6NZ/SCE+W64i6vEbjOy6U+Z
ESzpP3/dQ1YMPcRUK5UyOSejj3f598m31lWS6nICO1LO25mCCsnOljdjzS6llr6g6C4TKNGwaK7J
C7PHlEPwsq+3c/WsD2X09f17AGUr46kKZW5kc3RyZWFtDWVuZG9iag0xNyAwIG9iag08PCANL1R5
cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCAN
L0ZsYWdzIDY4IA0vRm9udEJCb3ggWyAtMzIgLTI1MCAxMDQ4IDc1MCBdIA0vRm9udE5hbWUgL0pP
TEdHSytDTU1JMTAgDS9JdGFsaWNBbmdsZSAtMTQuMDM5OTkgDS9TdGVtViA3MiANL1N0ZW1IIDMx
IA0vQ2hhclNldCAoL2NoaSkNL0ZvbnRGaWxlMyAxOCAwIFIgDT4+IA1lbmRvYmoNMTggMCBvYmoN
PDwgL0xlbmd0aCAzNTkgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQoBAAQCAAEBAQ5KT0xH
R0srQ01NSTEwAAEBASf4HAH4FwQe4UoE/wwC+B0MFmv7jvqs+YIF9ywP9y8Q9zIRq/faEgADAQEE
SU9jaGlDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHkuIEFs
bCBSaWdodHMgUmVzZXJ2ZWRDTU1JMTAAAAABhwABHwACAQEHo/8BTVVWDv8CcbE8+2Gh+O+hAfjb
+CcVlpaLjY4akYeRg4WHhoSFHvt5+5Nj9xODpHTAGaKAdb0zG1FxV32Ki4KXlI2RkI0fspqrj5Eb
qak/X5wfqzyr+wiIGoqLiYODHvt6+5UFgICLiYgahZGFkZKQko+PHvd595WrI5dko1MZbZihWeQb
xaa/mJCJkYGBioeBiB9zgnJ7eBtYR/eG2HUfDnWh+T+h+6aWlpgG+2GWBx6gQ3kAAf8MCaoK0wuk
kQwMCmVuZHN0cmVhbQ1lbmRvYmoNMTkgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciAN
L0FzY2VudCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFncyAyNjIxNzggDS9Gb250
QkJveCBbIC01MyAtMjUxIDExMzkgNzUwIF0gDS9Gb250TmFtZSAvSk9MR0ZGK0NNQlgxMiANL0l0
YWxpY0FuZ2xlIDAgDS9TdGVtViAxMDkgDS9TdGVtSCA0MyANL0NoYXJTZXQgKC90d28vcGVyaW9k
L29uZS9NL2kvbi9tL2EvbC9zL3QvZi9vL3IvRy9lL2MvdGhyZWUvRC9xdW90ZXJpZ2h0KQ0vRm9u
dEZpbGUzIDIwIDAgUiANPj4gDWVuZG9iag0yMCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29k
ZSAvTGVuZ3RoIDE5OTggL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiZRVa1AU6RXtppnp
kcVxZW0f06R72JWIjxVxrSipuIogPllZieIuKjMjCMP7OchDgZHXzMeggwjKcxgRAQcRgRbRIKvG
WjW+HxuNxq2NpVWG6K7Evc1+bpEGrVSSyo/kR//o/uqec+695ztNEs5OBEmSytXr1q4IDJztH7Rs
k8/80S+8yJLiJGfR3XXyRrzH3Tl12CgD9QRYPvGsu6LTjXAiycC1/olJmSn6qOg0tZf/TLWPr+9C
tV98ZIp+mzZBHaRNi46M16ZJL3HqkMRt+si0zLlqv7g49frRilT1+sjUyBRDZMQ7ToIkFAQxgSDc
nAhPgvAiiLkEsYwgAggikCRWE0QQRYQ4EYykl6ClAy1hI98nG0nRqZz6kKp3dnaOd74smyjzk30j
XyKvlL+k99K3RkZu5xFKNYg28IPp5GNYQEGUeJMxLY4JCtmqMO42m4tVxqp868EfHsO0qzHnQsKT
YiKimqL6Wuqq9+3jlGo0Vjadgh23me6YtoiImDidzhF34oSjrZtTIkEsE042kLATZBS8GKaZFhOK
5db4YQqlszs09fJjA9YDXfybRsxraEvP31Ef2/camXp4Af+CViJwgSswrV8gz8M0CIZJlGiBWEYr
LzEUBOfkKwp2L0Y5LPaWdx59+k11pQKoP1/v/6sKXNS38FQsm7VmzkYhx97WYTvVE2eL28Od6hrY
Y2OfnVzqv3ijv07D43icIcs3IlOmKktcRCtzu04AB27HHsOkng7yPjhBEHhQcBAeM+CMPgrbijww
YVhV1h7GCxXVba2q7oQWnTYhQev9cgNMAN8HT1+eSXmOvZu5vzR/femB6p7/ZcxjZ9/gX39xIvtw
y7H6U/b89s3lXHfPdWRln6DA+PjiLbE6PlmfbIo05ZozzMUmRWEJKihWZVlRA6ccIfsuBEhDHBRI
mA4fiO7gTnUOL2M0r98MemhEXxp+C14ScwwY8ByYgIN5HPzzFEYchFn0dzf1ocf5Fl39l5hR4XE5
odGbuS3RK2N8WAn2xld3cgUIE0Q3gbwEHuJ8mEoN50MWc1+Qm1LVKJb9bBWyfMZrwMOTNqDEbSnc
roy4fC273uvgnSA+ojf1a3BVvaq92TvA3bvycv9p9h6M1+KAVt5oqUBVrB1ZDvGQQNtRWTq31F92
OmTlIT8W78ZzsSfejnUwE88E07UH1QPdfGz7hdQytgrtr+GVI07FjSvfNTyjTxwCF0pshQ8YXCAe
k9mMRmRgsV7q/po83WxOLuZMmRnmTDZNI7fY76Mj7JEHyGTnhTQ6yYTKUvmEPebSRpV4rpSGpjc/
yvL2WvNr2Vrr/sq9PLQOO8lKR6cotzQPoXa2fQiZmnnBQxx8LWA9bZCojJIeIldDFDpA1wwLHGQ7
UKADkhI1cJZ5tuwS9gjBLkULtUczm1tbbJ31BXVZlVyF4xCqZ693R/ry22g8H38Sjql5oMi48ccz
PScb+O1I8z3XL7ftQ402I9rJry1FNXYVJs8zHy/MjP1S5zj1FIi2v+2Vlk8E5xGFHeKUDrITXGHF
6CyiYRxTlYfys83m3CJuR0HSSm8WeyCY03uxFKbAlPKLpiKz2Wwy8yUlu3JSVNr2rCZb54G+R5i2
bsCBy7EC09j9uTfMAJ82UJSPsmy5dqGwA0Ja4FMH2SYRGZ9R4iZIZuxW1NRacG9LH9+jDTnwOYvn
/coTu2H1q3kwG2b3vq6tzkGF2eaSXYX86uRVhjAWe5qBPc+3OFu6S0/YOhRH6481CuyPFdj1i1Jp
lCPdSwkkwE8CpDpIkA09AQUF8aInA3IBv/dKPnS1xlFpMZusXE6+Mcug2nY083BjR/XJ7qiegHmY
isQKztNPcxf/FChFhf2etO6Wh8h0iBcW0FIOCSD2fy+FkQRMQeowNZZGujh9ZGSbvnssjXAAXsVo
6IvlKILHN8dAbqBm9siVMZAgcfYYjDjY/xYjfng1g/12yzT0pdGKN78fq7glVTTfGnNZIK0Uq6UC
F6kbCkgIf/tMWjT8LVxknkWcxc6/3LwiNpv7NntF9Rp2dmhQmIE3g5McL/4n6jsdt0e9e+ctKuhp
IB+evXy8MX0xh5v/73NaWunVPOJfhG0dtewRSdNz3Rns5B8UvVTP/W86iD8NXDluS13y33kkb6re
WqYKXCmxGRIZYL1fYB+8cMFHeDKe8uxj8IGF370ANw5b8OcMnoxg3KM+9Lv6Dr6rsbdOYC90JCXW
8g1RKDRMtQhJ7mRGHTnj56S38oeGXo2aJALSGUc5fALjuJ15BVmZKp0jq6nJUdvdH3ok7Df6QO1O
qR9Kjhf9Zz//bpIRYupS6TKL6lay8zpkX6fE8eISph6V5xSakDGHKy7JKygqUdQkbrdGsfF4FsKT
P4T309uK+KJmR+EetsvYlaJVfToPGTatrRlM5BoKzaVZrAGVpPGYpneggupyC6pp4A7Xy6J7v0J1
7DmYWAXTTic7Mup4XbveumG/Yk3lusrTqj88QTagrMtTLNyu0n1SXtpQmZ1X1kkTpQVY0kD+IK1t
fM/oz1i6HtMFPB1CtHKzV5iXV4ki5iFuoz0epd2+e/L8XW5AG0qvik+IW4eu2TllbtXwsipcXgHh
DXK8pZzmbP6ZBDniOk5wAfK99gpXVyDtruNLXZXcxlnhkzi/6nDmHwMASQ03vwplbmRzdHJlYW0N
ZW5kb2JqDTIxIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0Nh
cEhlaWdodCAwIA0vRGVzY2VudCAwIA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC0zNiAtMjUwIDEw
NzAgNzUwIF0gDS9Gb250TmFtZSAvSk9MR0VBK0NNUjggDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYg
NzYgDS9TdGVtSCAzMyANL0NoYXJTZXQgKC9vbmUvdHdvKQ0vRm9udEZpbGUzIDIyIDAgUiANPj4g
DWVuZG9iag0yMiAwIG9iag08PCAvTGVuZ3RoIDM3NyAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJl
YW0NCgEABAIAAQEBDEpPTEdFQStDTVI4AAEBAR34GwH4FwT4HAwWZ/uO+sL5ggX3Gg/3HhG999oS
AAIBAUZKQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5LiBB
bGwgUmlnaHRzIFJlc2VydmVkQ01SOAAAAQASAQADAQEDR7YgDous+Kust58B93/aA/fO+REVpomM
cB5jYlZzLBtqB6bBi6bFH/yVB2aIfyweaGoGjrThi7gbuOKLiLQfrGgHLIiXsB8Oi9337/TtrAHA
9Pd06gP3rvdgFZuataybmQjJxMbC5hr3CyfY+xH7DDwwMlqyhJmgqpqxv1mLfx7UqM6kvBvouzw3
I0I/+wr7DR/7EvsWBX+Ai4lyGvgfBqj3RwVsBoh3g1l/eAiDhT+Lexv7RgYOdqD5P6D7pZr3b5UG
+2GWBx6gQ3kAAf8MCawK1wunkAwM15sMDR5TGiX/FB5GGhZmbxUKZW5kc3RyZWFtDWVuZG9iag0y
MyAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDAgDS9DYXBIZWlnaHQg
MCANL0Rlc2NlbnQgMCANL0ZsYWdzIDk2IA0vRm9udEJCb3ggWyAtMzAgLTk1NSAxMTg1IDc3OSBd
IA0vRm9udE5hbWUgL0pPTEdERitDTVNZOCANL0l0YWxpY0FuZ2xlIC0xNC4wMzUgDS9TdGVtViA4
OSANL1N0ZW1IIDQ2IA0vQ2hhclNldCAoL21pbnVzKQ0vRm9udEZpbGUzIDI0IDAgUiANPj4gDWVu
ZG9iag0yNCAwIG9iag08PCAvTGVuZ3RoIDIxMyAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0N
CgEABAEAAQEBDUpPTEdERitDTVNZOAABAQEl+BsB+BcEHuFKA18MAvgcDBZt/k8cBKH5nwX3JA/3
JxGd91YSAAIBAUZLQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2Np
ZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkQ01TWTgAAAAApgACAQECKg7/AzpmaPd3uQHk+RsD+VD3
dxWZoYuionWLfR/80wZ9dYt0dKGLmR8Oc6P5P6AG+xKTB7kK5Au5mgwMCmVuZHN0cmVhbQ1lbmRv
YmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvY2hpIF0g
DT4+IA1lbmRvYmoNMjYgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMTUg
Pj4gDXN0cmVhbQ0KSIlUUDFuwzAM3PUKjgkyyEqHLIYXFwU8NC3qtLsi0a6AmhJoefDvIyluig48
gEce7kjZds8duQjynb3pMcLgyDLOfmGDcMXREagjWGfi1hU0kw4gk7hf54hTR4OHuhbyIw3nyCvs
XlR1qPYg39giOxphd1GfX4nolxB+cEKKUEHTgMVByPZVh7OeEGTR/ZGXNSAcS682a29xDtogaxoR
6ko1d0Cy/2e/iutgvjWLbfOpPTUi7W5sVuVjHgnMwpzClYtLhGzuCB9PCT5kr1ziJsAAHWlovApl
bmRzdHJlYW0NZW5kb2JqDTI3IDAgb2JqDTw8IA0vUyAvRCANPj4gDWVuZG9iag0yOCAwIG9iag08
PCANL051bXMgWyAwIDI3IDAgUiBdIA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vVHlwZSAvUGFn
ZXMgDS9LaWRzIFsgMzQgMCBSIDEgMCBSIDQgMCBSIDcgMCBSIF0gDS9Db3VudCA0IA0+PiANZW5k
b2JqDTMwIDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDMwNDIyMTIwOTMwLTA0JzAwJykN
L01vZERhdGUgKEQ6MjAwMzA0MjIxMjA5MzAtMDQnMDAnKQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlz
dGlsbGVyIDUuMC41IFwoV2luZG93c1wpKQ0vQ3JlYXRvciAoZHZpcHMgNS43MCBDb3B5cmlnaHQg
MTk5NyBSYWRpY2FsIEV5ZSBTb2Z0d2FyZSBcKHd3dy5yYWRpY2FsZXllLmNvbVwpKQ0vVGl0bGUg
KHNwZWN0cnVtLmR2aSkNPj4gDWVuZG9iag0zMSAwIG9iag08PCAvVHlwZSAvTWV0YWRhdGEgL1N1
YnR5cGUgL1hNTCAvTGVuZ3RoIDEwMzEgPj4gDXN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPScnIGlk
PSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnIGJ5dGVzPScxMDMwJz8+PHJkZjpSREYgeG1sbnM6
cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczpp
WD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz48cmRmOkRlc2NyaXB0aW9uIGFib3V0PScn
IHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyB4bWxuczpwZGY9J2h0dHA6Ly9u
cy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpDcmVhdGlvbkRhdGU9JzIwMDMtMDQtMjJUMTY6MDk6
MzBaJyBwZGY6TW9kRGF0ZT0nMjAwMy0wNC0yMlQxNjowOTozMFonIHBkZjpQcm9kdWNlcj0nQWNy
b2JhdCBEaXN0aWxsZXIgNS4wLjUgKFdpbmRvd3MpJyBwZGY6VGl0bGU9J3NwZWN0cnVtLmR2aSc+
PHBkZjpDcmVhdG9yPmR2aXBzIDUuNzAgQ29weXJpZ2h0IDE5OTcgUmFkaWNhbCBFeWUgU29mdHdh
cmUgKHd3dy5yYWRpY2FsZXllLmNvbSk8L3BkZjpDcmVhdG9yPjwvcmRmOkRlc2NyaXB0aW9uPgo8
cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x
LjAvJyB4bWxuczp4YXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpDcmVhdGVE
YXRlPScyMDAzLTA0LTIyVDE2OjA5OjMwWicgeGFwOk1vZGlmeURhdGU9JzIwMDMtMDQtMjJUMTY6
MDk6MzBaJyB4YXA6TWV0YWRhdGFEYXRlPScyMDAzLTA0LTIyVDE2OjA5OjMwWic+PHhhcDpUaXRs
ZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPnNwZWN0cnVtLmR2aTwvcmRm
OmxpPjwvcmRmOkFsdD48L3hhcDpUaXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPHJkZjpEZXNjcmlw
dGlvbiBhYm91dD0nJyB4bWxucz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIHht
bG5zOmRjPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6dGl0bGU9J3NwZWN0
cnVtLmR2aScvPgo8L3JkZjpSREY+PD94cGFja2V0IGVuZD0ncic/PgplbmRzdHJlYW0NZW5kb2Jq
DXhyZWYNMCAzMiANMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDI3NTgyIDAwMDAwIG4NCjAwMDAw
Mjc3MzMgMDAwMDAgbg0KMDAwMDAyNzg5MSAwMDAwMCBuDQowMDAwMDMzNDkzIDAwMDAwIG4NCjAw
MDAwMzM2NDQgMDAwMDAgbg0KMDAwMDAzMzc3OSAwMDAwMCBuDQowMDAwMDM4NjU5IDAwMDAwIG4N
CjAwMDAwMzg4MTAgMDAwMDAgbg0KMDAwMDAzODk0NiAwMDAwMCBuDQowMDAwMDQyMjY0IDAwMDAw
IG4NCjAwMDAwNDI0MzEgMDAwMDAgbg0KMDAwMDA0MjYxMSAwMDAwMCBuDQowMDAwMDQzMDMyIDAw
MDAwIG4NCjAwMDAwNDMyMTcgMDAwMDAgbg0KMDAwMDA0MzUxMSAwMDAwMCBuDQowMDAwMDQzNzY2
IDAwMDAwIG4NCjAwMDAwNDUyOTkgMDAwMDAgbg0KMDAwMDA0NTUzNCAwMDAwMCBuDQowMDAwMDQ1
OTYzIDAwMDAwIG4NCjAwMDAwNDYyNTMgMDAwMDAgbg0KMDAwMDA0ODM0MyAwMDAwMCBuDQowMDAw
MDQ4NTcyIDAwMDAwIG4NCjAwMDAwNDkwMTkgMDAwMDAgbg0KMDAwMDA0OTI1MyAwMDAwMCBuDQow
MDAwMDQ5NTM2IDAwMDAwIG4NCjAwMDAwNDk2MDIgMDAwMDAgbg0KMDAwMDA0OTg5MSAwMDAwMCBu
DQowMDAwMDQ5OTIyIDAwMDAwIG4NCjAwMDAwNDk5NjYgMDAwMDAgbg0KMDAwMDA1MDA1MCAwMDAw
MCBuDQowMDAwMDUwMzAwIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgMzINL0lEWzxmZDE3ZjQ1
OWZhYmZhNDc0MGM2MWZiY2Q5OWYxNzE4Yz48ODBmOTBmM2YzYmU5ZjllN2ExYjI1YzhkM2IxMGU1
M2E+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ==

------=_NextPart_000_005C_01C308CD.C4CAD190--

From - Wed Apr 23 10:27:26 2003
X-UIDL: 3e5baf6500000648
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3MHYIhr022564
	for <dal@ivoa.net>; Tue, 22 Apr 2003 19:34:18 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3MHYHU14388
	for <dal@ivoa.net>; Tue, 22 Apr 2003 19:34:17 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA5HaOfC; Tue, 22 Apr 03 19:34:16 +0200
Received: from cfa.harvard.edu (pioneer [131.142.184.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h3MHQfbo027542;
	Tue, 22 Apr 2003 13:26:41 -0400 (EDT)
Message-ID: <3EA57B51.3060802@cfa.harvard.edu>
Date: Tue, 22 Apr 2003 13:26:41 -0400
From: Steve Lowe <slowe@cfa.harvard.edu>
Organization: SAO / CfA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dal@ivoa.net, metadata@us-vo.org
Subject: SIAP Document from SAO/CfA
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Hi All,

I have uploaded a document on extending SIAP to the US-VO Publications 
Repository. The URL is:
    
http://bill.cacr.caltech.edu/cfdocs/usvo-pubs/files/SIAPSpec_Part1_v1_0.pdf

As I say in the report, it is a combination of a Request for Comments 
and a partial Specification that reflects the ideas we are kicking 
around here at CfA. The release of Arnold's requirements document about 
the time of the Pasadena meeting stirred up a lot of discussion, and I 
hope that this new report will do likewise.

Steve

-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe@cfa.harvard.edu
1-617-496-1661


From - Wed Apr 23 10:27:26 2003
X-UIDL: 3e5baf650000064a
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3MJBHhr013935
	for <dal@ivoa.net>; Tue, 22 Apr 2003 21:11:17 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3MJBGB22489
	for <dal@ivoa.net>; Tue, 22 Apr 2003 21:11:16 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAEoaa7R; Tue, 22 Apr 03 21:11:15 +0200
Received: from cfa.harvard.edu (pioneer [131.142.184.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h3MJ3jbo002694;
	Tue, 22 Apr 2003 15:03:45 -0400 (EDT)
Message-ID: <3EA59211.7060603@cfa.harvard.edu>
Date: Tue, 22 Apr 2003 15:03:45 -0400
From: Steve Lowe <slowe@cfa.harvard.edu>
Organization: SAO / CfA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dal@ivoa.net, metadata@us-vo.org
Subject: Re: SIAP Document from SAO/CfA
References: <3EA57B51.3060802@cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Hi all,

As several folks pointed out, the file I uploaded before was actually 
PostScript, not PDF. I've now replaced the repository entry with a new 
version which is PDF, but for some reason the file name got changed on 
upload. You can just get the file via the doc repository, or use the new 
direct link:
http://bill.cacr.caltech.edu/cfdocs/usvo-pubs/files/ACFE3.pdf

If anyone has any other problems, just let me know.

Steve

Steve Lowe wrote:

> Hi All,
>
> I have uploaded a document on extending SIAP to the US-VO Publications 
> Repository. The URL is:
> http://bill.cacr.caltech.edu/cfdocs/usvo-pubs/files/SIAPSpec_Part1_v1_0.pdf 
>
>
> As I say in the report, it is a combination of a Request for Comments 
> and a partial Specification that reflects the ideas we are kicking 
> around here at CfA. The release of Arnold's requirements document 
> about the time of the Pasadena meeting stirred up a lot of discussion, 
> and I hope that this new report will do likewise.
>
> Steve
>


-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe@cfa.harvard.edu
1-617-496-1661



From - Wed Apr 23 10:27:27 2003
X-UIDL: 3e5baf650000064d
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3MKnThr013676
	for <dal@ivoa.net>; Tue, 22 Apr 2003 22:49:29 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3MKnSg00382
	for <dal@ivoa.net>; Tue, 22 Apr 2003 22:49:28 +0200 (MEST)
Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAgOaiVa; Tue, 22 Apr 03 22:49:27 +0200
Received: from stsci.edu (dsl081-096-059.den1.dsl.speakeasy.net [64.81.96.59])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AEA20144 (AUTH gaffney);
	Tue, 22 Apr 2003 16:49:23 -0400 (EDT)
Message-ID: <3EA5AAED.9080600@stsci.edu>
Date: Tue, 22 Apr 2003 14:49:49 -0600
From: Niall Gaffney <gaffney@stsci.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Steve Lowe <slowe@cfa.harvard.edu>
CC: dal@ivoa.net, metadata@us-vo.org
Subject: Re: SIAP Document from SAO/CfA
References: <3EA57B51.3060802@cfa.harvard.edu>
In-Reply-To: <3EA57B51.3060802@cfa.harvard.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Steve,

Four comments on the first read through.

1> At this point I think we should call this thing something different.  
First off...its not Simple to me anymore.  Its becoming very general 
actually.  Also its no longer limited to Images, but to astronomical 
data in general.  So isn't this now a Data Access Protocol?  I know this 
may be nit picking but as I was reading this I had to remind myself over 
and over that this is not simple and is for more than images. With that 
behind me things were easier to contemplate.

2> With acceptance of the fact that this is no longer Simple, we need to 
add to the list of Principal Ideas: Error/Exception Reporting.  With SIA 
1.0 an error was either that you didn't format something the way I 
wanted it or I dont have what you need for other reasons (e.g. you got 
an http error 500 as the script you were running crashed).  With all of 
these capabilites must come some consistant error reporting methods.  
This has to be defined in the protocol and should be made in parallel as 
we expand this protocol, not patched on at the end. 

3> One challenge I saw from 6.3 Coordinate for data products is there is 
no mention of 2d long slit spectra. This is when spectra differ the most 
from images in their metadata as orientation is a very big deal. In 
UV/Optical/IR data, this is the typical mode of a pointed spectrometer.  
Do we need more in our ROI_COORDS to cover this (say a position angle 
and spatial length) and/or is there an orient and shape to describe the 
returned data's slit orientation on the sky? 

4>  I really like the structure proposed in 6.6.  We got into a 
discussion in the context of the Registry when we were trying to look at 
some "isA" relationships for services.  Here this sort of breaks things 
down well, so it is simple from the responce for the metadata for a 
query service to tell if it can be queried on parameters that are the 
same as that of others simply by looking at the ROI_QUANTITIES.  The 
ROI_COORDSYS tells you when you will have to do nonliner transformations 
of query data to make it match what you want (FK5->FK4 or lambda to 
frequency) and units are the simplest translations (appart from mJy to 
magnetudes).  It makes it clear to the querier what level of comitment 
will be needed to make things work together and allows them to set the 
bar as high or low as they want without writing a complex parser/comparitor.

And one last thing is something I can see coming back to haunt some 
users.  We use commas to delineate things in the ROI_* in 6.6.  We also 
use it in the coordinate where it joins a pair of paremeters into a set 
for one entity.  This symbol overloading makes perfect sence to those 
who know mathematics, but to poorly instructed string parsing code, 
ROI_QUANTITIES And ROI_COORDSYS have 2 data entitites and the RIO_UNITS 
has three (if you are not clever and do something about the 
paretheses).  Can we pick a different symbol for one of these (say , are 
for grouping numbers into sets like coordinates and ; are the other 
delineator)? 

Niall

Steve Lowe wrote:

> Hi All,
>
> I have uploaded a document on extending SIAP to the US-VO Publications 
> Repository. The URL is:
>    
> http://bill.cacr.caltech.edu/cfdocs/usvo-pubs/files/SIAPSpec_Part1_v1_0.pdf 
>
>
> As I say in the report, it is a combination of a Request for Comments 
> and a partial Specification that reflects the ideas we are kicking 
> around here at CfA. The release of Arnold's requirements document 
> about the time of the Pasadena meeting stirred up a lot of discussion, 
> and I hope that this new report will do likewise.
>
> Steve
>

From - Wed Apr 23 10:27:27 2003
X-UIDL: 3e5baf6500000653
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3MN3miu009897
	for <dal@ivoa.net>; Wed, 23 Apr 2003 01:03:48 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3MN3mB05928
	for <dal@ivoa.net>; Wed, 23 Apr 2003 01:03:48 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAgsayKl; Wed, 23 Apr 03 01:03:47 +0200
Received: from cfa.harvard.edu (pioneer [131.142.184.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h3MMuGbo011480;
	Tue, 22 Apr 2003 18:56:16 -0400 (EDT)
Message-ID: <3EA5C890.5020706@cfa.harvard.edu>
Date: Tue, 22 Apr 2003 18:56:16 -0400
From: Steve Lowe <slowe@cfa.harvard.edu>
Organization: SAO / CfA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Niall Gaffney <gaffney@stsci.edu>
CC: dal@ivoa.net, metadata@us-vo.org
Subject: Re: SIAP Document from SAO/CfA
References: <3EA57B51.3060802@cfa.harvard.edu> <3EA5AAED.9080600@stsci.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Niall Gaffney wrote:

> 1> At this point I think we should call this thing something 
> different.  First off...its not Simple to me anymore.  Its becoming 
> very general actually.

We were thinking of, perhaps, Data Product Access Protocol, but your 
suggestion of Data Access Protocol would also be good. As to, the 
simplicity, well, we're trying to not make it any more complicated than 
we have too.

> 2> With acceptance of the fact that this is no longer Simple, we need 
> to add to the list of Principal Ideas: Error/Exception Reporting.  
> With SIA 1.0 an error was either that you didn't format something the 
> way I wanted it or I dont have what you need for other reasons (e.g. 
> you got an http error 500 as the script you were running crashed).  
> With all of these capabilites must come some consistant error 
> reporting methods.  This has to be defined in the protocol and should 
> be made in parallel as we expand this protocol, not patched on at the end.

I agree, and we haven't done too much with this other than to 
acknowledge that it needs to be there.

> 3> One challenge I saw from 6.3 Coordinate for data products is there 
> is no mention of 2d long slit spectra. This is when spectra differ the 
> most from images in their metadata as orientation is a very big deal. 
> In UV/Optical/IR data, this is the typical mode of a pointed 
> spectrometer.  Do we need more in our ROI_COORDS to cover this (say a 
> position angle and spatial length) and/or is there an orient and shape 
> to describe the returned data's slit orientation on the sky? 

Absolutely! This has been a concern of ours that we've been working on, 
but are still not sure of the best approach and will discuss it in the 
next Part of this report. We went ahead and distributed "Part 1" because 
we wanted to get some discussion going on the whole idea of introducing 
other coordinates and how to do that.
Perhaps the simplest thing to do for slit spectra is to introduce a 
property SKY:DIST:SUBSPC1 that can be used as an AXIS coordinate to 
request a data product which is a one-dimensional subspace of the 2-D 
SKY:DIST space. (I could have used "SLIT", instead of "SUBSPC1", but we 
want this to be general, no?) But, suppose you were only interested in a 
specified slit orientation, e.g., along the (apparent) long axis of a 
particular galaxy you are studying. Now you need an input parameters to 
indicate the orientation of the slit (actually, an acceptable range for 
the orientation). But then we have to decide how to add this extra 
parameter to the protocol in a general way. One way would be to tack the 
parameter on as an argument, e.g., the service coordinate list could 
have an entry
    AXIS    SKY:DIST:SUBSPC1(ANGLE)
to indicate that a request can be made for a 1-D piece of the sky at a 
specified angle ANGLE.
But the angle has to have units! So, now the entry has to be something like
    AXIS    SKY:DIST:SUBSPC1(ANGLE:DEG)
So, it get's a little complicated, and we wanted to get it refined a 
little more in our own minds before sending it out. Also, this matter of 
continuously parameterized families of coordinate systems turns up 
elsewhere, for example if you're thinking of nearby objects and have to 
worry about where the telescope is located---i.e., dealing with other 
projections of the sky than the "distant" idealization. The DIST in 
SKY:DIST has an ominous future ahead.

> 4>  I really like the structure proposed in 6.6.  We got into a 
> discussion in the context of the Registry when we were trying to look 
> at some "isA" relationships for services.  Here this sort of breaks 
> things down well, so it is simple from the responce for the metadata 
> for a query service to tell if it can be queried on parameters that 
> are the same as that of others simply by looking at the 
> ROI_QUANTITIES.  The ROI_COORDSYS tells you when you will have to do 
> nonliner transformations of query data to make it match what you want 
> (FK5->FK4 or lambda to frequency) and units are the simplest 
> translations (appart from mJy to magnetudes).  It makes it clear to 
> the querier what level of comitment will be needed to make things work 
> together and allows them to set the bar as high or low as they want 
> without writing a complex parser/comparitor. 

I'm glad to hear that you like the property/coordsys/units breakdown 
presented in 6.6. Building that factorization into the protocol may 
indeed be the right way to go, we're not sure yet. Your vote is 
registered! The reason for proposing the unstructured strings was the 
thought that some elements will expand into subelements, as with 
SKY:DIST:SUBSPC1 above, or for example that the common non-ICRS 
equatorial systems require a couple of defining values instead of just 
one, i.e., EQUAT:ICRS but EQUAT:J2000:FK5 or EQUAT:B1950:FK4. Then one 
starts to ask whether some users would find it useful if these elements 
were broken out as well. What is the right breakdown? 
Property/coordsys/units does seem intuitive, but it may be that, for a 
machine-to-machine protocol (as opposed to a human-usage oriented 
protocol), we can just punt the whole question by not building any 
structure at all into the protocol, and just have the factorization 
implied by common usage.

> And one last thing is something I can see coming back to haunt some 
> users.  We use commas to delineate things in the ROI_* in 6.6.  We 
> also use it in the coordinate where it joins a pair of paremeters into 
> a set for one entity.  This symbol overloading makes perfect sence to 
> those who know mathematics, but to poorly instructed string parsing 
> code, ROI_QUANTITIES And ROI_COORDSYS have 2 data entitites and the 
> RIO_UNITS has three (if you are not clever and do something about the 
> paretheses).  Can we pick a different symbol for one of these (say , 
> are for grouping numbers into sets like coordinates and ; are the 
> other delineator)? 

Ah, the intention was that the parentheses in 
ROI_UNITS=(DEG,DEG),ANGSTROM would be parsed. I see your point, you 
can't just break it up with split(","). We'll give it some thought.

Regards,
Steve

-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe@cfa.harvard.edu
1-617-496-1661



From - Wed Apr 23 11:25:23 2003
X-UIDL: 3e5baf650000065a
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3N9LKiu013047
	for <dal@ivoa.net>; Wed, 23 Apr 2003 11:21:20 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3N9LKo23843
	for <dal@ivoa.net>; Wed, 23 Apr 2003 11:21:20 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAGlaqKU; Wed, 23 Apr 03 11:21:19 +0200
Received: from newb6.u-strasbg.fr (gecko.u-strasbg.fr [130.79.129.108])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h3N9JwWI055685
          for <dal@ivoa.net>; Wed, 23 Apr 2003 11:20:03 +0200 (CEST)
Message-ID: <3EA65CB9.3000704@newb6.u-strasbg.fr>
Date: Wed, 23 Apr 2003 11:28:25 +0200
From: "Mark G.Allen" <allen@newb6.u-strasbg.fr>
Reply-To: allen@newb6.u-strasbg.fr
Organization: Observatoire de Strasbourg
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: dal@ivoa.net
Subject: =?ISO-8859-1?Q?Re=3A_Re=3A_Metadata_tree_Some_document?=
 =?ISO-8859-1?Q?ation_for_a_metadata-tree_=3D=3D=3D=3D=3D=3D=3D=3D?=
 =?ISO-8859-1?Q?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D?=
 =?ISO-8859-1?Q?=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D_Mark_Allen_and_?=
 =?ISO-8859-1?Q?Fran=E7ois_Bonnarel_Version_0=2E0?=
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: scanned by sophos at u-strasbg.fr
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   


Just to be clear, Francois Bonnarel did all the work for this and I
helped write the document. Francois should have put his name first. 

-Mark.



From - Wed Apr 23 19:40:23 2003
X-UIDL: 3e5baf6500000671
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3NHcpiu024187
	for <dm@ivoa.net>; Wed, 23 Apr 2003 19:38:51 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3NHcon17396
	for <dm@ivoa.net>; Wed, 23 Apr 2003 19:38:50 +0200 (MEST)
Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA69ai_H; Wed, 23 Apr 03 19:38:49 +0200
Received: from stsci.edu (winds.stsci.edu [130.167.236.235])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AEA48540;
	Wed, 23 Apr 2003 13:38:46 -0400 (EDT)
Message-ID: <3EA6CFA6.2E1D0CF5@stsci.edu>
Date: Wed, 23 Apr 2003 13:38:46 -0400
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: dal@ivoa.not, dm@ivoa.net
Subject: Spectral standards
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   


I would like to complement the contents of my write-up on spectral 
data structures with an important point.

In the Specview design we almost completely swept under the rug the
issue of spectral resolution. This is something I should have added to
my write-up, but forgot. The reason is that originally Specview was
conceived as basically a visualization tool, with no data analysis
capabilities. And most of my recent work on it has emphasized the
visualization side.

When we added the ability to fit models to data, and now when we are 
adding other data processing and analysis capabilities to it, we face 
the problem of how to handle resolution issues when the input data 
itself doesn't carry explicit resolution information. For instance,
we need to know what is the effective resolution of each sample when
computing a chi-squared metric between the data and a spectral model.
When using the current version of Specview to fit a model to a 
composite data set made out of data pieces generated by different 
instruments, the chi-squared computation may be more or less biased 
depending on the differences in resolution between the instruments. 

We have a plan to address this issue in a future release of Specview, 
but my aim here is to emphasize this important aspect of spectral data 
that, in my view, should be an integral part of any VO spectral standard.

-Ivo

From - Wed Apr 23 20:20:23 2003
X-UIDL: 3e5baf6500000675
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3NIKMiu014156;
	Wed, 23 Apr 2003 20:20:23 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h3NINdF15065;
	Wed, 23 Apr 2003 20:23:39 +0200 (MEST)
Message-ID: <3EA6D92C.6020109@eso.org>
Date: Wed, 23 Apr 2003 20:19:24 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: dal@ivoa.net, metadata@us-vo.org
Subject: Re: SIAP Document from SAO/CfA
References: <3EA57B51.3060802@cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

 > 1> At this point I think we should call this thing something different.
 > First off...its not Simple to me anymore.  Its becoming very general
 > actually.  Also its no longer limited to Images, but to astronomical
 > data in general.  So isn't this now a Data Access Protocol?

That's why this particular mailing list of the International Virtual 
Observatory Alliance IVOA was called data access layer DAL instead of 
SIAP. To be fair it needs to be said that work on SIAP started before 
there was an IVOA and therefore the original SIAP document cannot 
reflect the current IVOA structure. There are six areas of IVOA 
(technical) activities and to my understanding DAL is building upon the 
other 5 which are in no particular order:

- data models <dm@ivoa.net>, Jonathan McDowell (lead)
- service registry <registry@ivoa.net>, Tony Linde
- formats <votable@ivoa.net>, Francoise Genova
- meta data <ucd@ivoa.net>, Roy Williams
- query language(s) <voql@ivoa.net>, Masatoshi Oishi
- data access layer <dal@ivoa.net>, Doug Tody

Hint: In order to reach all above groups at once you may post messages 
to <interop@ivoa.net>. Sorry to those who heard this before.

Markus

From - Mon Apr 28 23:59:48 2003
X-UIDL: 3e5baf650000071e
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3SLxqWg009241
	for <dal@ivoa.net>; Mon, 28 Apr 2003 23:59:52 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3SLxqR01389
	for <dal@ivoa.net>; Mon, 28 Apr 2003 23:59:52 +0200 (MEST)
Received: from noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAIpaGTc; Mon, 28 Apr 03 23:59:51 +0200
Received: from puppis.tuc.noao.edu ([140.252.4.30] verified)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 7205400 for dal@ivoa.net; Mon, 28 Apr 2003 14:58:34 -0700
Received: (from valdes@localhost)
	by puppis.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) id OAA11119
	for dal@ivoa.net; Mon, 28 Apr 2003 14:58:34 -0700 (MST)
Date: Mon, 28 Apr 2003 14:58:34 -0700 (MST)
From: Frank Valdes <valdes@noao.edu>
Message-Id: <200304282158.OAA11119@puppis.tuc.noao.edu>
To: dal@ivoa.net
Subject: Re: spectral data representations for the NVO
X-Sun-Charset: US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

    Incorporating Spectra in the Next Phase of the Virtual Observatory
		    Francisco Valdes, NOAO
			April 28, 2003


Abstract

For the most part astronomical images and spectra are both projections of a
four dimensional observational parameter space.  The four parameters are
two celestial coordinates, photon energy, and time.  The suggestion
presented here is that accessing these common forms of astronomical
observational data should be based on this four dimensional parameter
space.  The prototype for this would be a fairly direct extension of the
current "Simple Image Access Prototype" (SIAP) specification from the
current two dimensional parameter model.


Introduction

The two most common types of astronomical observations are images and
spectra.  Because spectroscopic instrumentation is generally different from
imaging, though many spectrometers/spectrographs include imaging modes, an
artificial distinction is made between images and spectra.  Also the way
spectral information is sometimes obtained by multiplexing photon energies
into spatial positions on a detector confuses the issues.  These factors
often lead to separate treatment for the two.

Conceptually, a majority of astronomical observational data consist of
measurements of photons arriving from a particular direction on the sky,
with a particular energy, and at a particular time.  Sometimes this
information is recorded directly in so-called event lists.  Other times
the events are binned to produce an array or raster which is implicitly
or explicitly four dimensional.

This picture of astronomical observations leads us to consider this class
of data as defined by the four parameters of celestial position, energy,
and time.  Note we refer to the spectral information in terms of photon
energy though wavelength or frequency could also be used as appropriate.
The discussion which follows does not expand on the time aspect of the
parameter space.  So the approach described here could also be defined to
consider a three dimensional space without the time element.  Time was
included, however, because it is a clearly identifiable aspect of the
observation model.

My vision for the VO access layer to observational astronomical data is
that the instrumental signatures and characteristics are removed by the
provider apart from the resolution or binning.  This is an important
requirement for dealing with spectra since the raw instrumental data can be
in quite complex formats with spatial and spectral information multiplexed
onto a detector.

The question addressed here is whether spectral data can be easily
incorporated in the current VO developmental framework.  In particular,
whether the "Simple Image Access Prototype Specification" (SIAP) might be
extended or if another prototype is needed for spectra.  In order to
consider a modest extension of SIAP, which is about raster data, the
observational data is also reqiured to be binned in the four dimensional
parameter space.  Event data can be accessed through such a model by
requiring the data provider bin the data for VO access through such a
raster protocol.

While we talk about a raster this does not mean the sampling is uniform in
any physical units.  What is meant by a raster is that a set of photon
values (such as flux or counts) is provided with a logical index.
Conversion from the logical index to a physical four dimensional parameter
space coordinate is the provence of the world coordinate system (WCS) and
of the discovery metadata.

Considerable thought has gone into expressing the relationship between
logical indices and world coordinates in the FITS WCS methods.
An important recent development is the proposal to allow lookup tables
as part of the relationship.  This is significant for spectra, particularly
1D projections, because the energy coordinates are sometimes provided
in a lookup table.  In other words, a common form of spectral data held
by data providers is a table of photon fluxes with associated energy.

While an lookup table was conceived of for spectra the concept can be
applied more broadly to the four parameter raster.  What this allows is
sparse sampling from the raster.  This might be relevant to some types
of spectral data where the spatial sampling is sparse and somewhat
random.  An example of this is multiobject spectroscopy where sources
are targeted with fibers.  Whether the instrumentally extracted spectra
should be considered separate rasters for the purposes of VO access
is an interesting point of discussion.


Data Access, Data Models, and Data Formats

A key distinction that needs to be reiterated in discussing data within
the virtual observatory context, is between data access/requests, data
models, and data formats.  We raise this here with regard to spectra
because it is easy to end up mixing all three.  The discussion here is focused
on data query and access for spectra.  Discovering and requesting data is
largely independent of the data format which is ultimately provided as the
result of a request.

In the context of SIAP, that specification mandates certain types of data
formats for retrieval.  The primary science type is FITS so in terms of
considering an extension of SIAP for spectra this implies a FITS data
format.  There are a variety of ways spectra can be included in FITS.  This
is the subject of the discussion by Busko and I can provide a similar
proposal for general spectral formats.  A discussion of the best few
formats for spectra might be diverse at first but I believe it would not be
hard to converge on a few that are FITS based and general enough; keeping
in mind that the vision is access to instrument independent science spectra
and not complex multiplexed data acquisition formats.

A key factor for the science formats is that they include a WCS.  The FITS
WCS, including lookup tables, has been developed to the point that it
provides fairly complete descriptions for images and spectra.  Note that
the non-linear distortion feature is still a proposal by Valdes and
others.

Projections of 4D Parameter Space -- Images and Spectra

This section identifies the obvious projections that constitute
observational images and spectra.  The first assertion is that for such
observational data there is one time value corresponding to a
representative instant in the observation (the start or midpoint).  The
second assertion is that an image is a spectrum with one energy point.
Both the time and energy points have metadata to define the point such as
exposure time and filter bandpass.

Spectra come in several flavors.  First, by definition, these have more
than one sample in energy.  The most complete spectral type is the
so-called data cube.  Data cubes include multiple raster elements in both
celestial coordinates and in energy.  These are generated by radio
spectrometers as well as Fabry-Perot and Integral Field Units at higher
energies.

Slit spectroscopy has been the mainstay of optical astronomy.  These are 2D
rasters with one celestial and one energy dimension.  The celestial
dimension requires a higher dimensional WCS in the metadata to convert the
spatial logical index to a curve in two dimensional celestial space.  There
are FITS WCS proposals for how this can be done in a general fashion.

Finally, fiber or spatially integrated spectra have just one point in
the spatial parameters.


Extensions of the SIAP Specification

The conclusion of the discusion presented here is that (raster indexed)
spectral data should be incorporated into the developing VO infrastructure
by avoiding any artificial distinction between images and spectra.
Therefore, one should extend the SIAP specification rather than invent a
new mechanism for spectra.  The concern about having the word "image"
in SIAP is recognized but not discussed here.

This discussion is not intended as a proposal but simply to explore how
spectra might be incorporated within the SIAP specification.  Many details
would have to be worked out.

In a broad review of the SIAP specification it appears that the main
changes required are to restate the purpose to include a more general
concept of "image" as potentially one to four dimensional data formats and
to extend the query and metadata fields appropriately.  In particular, the
discussion of queries would be expanded to a search for data in a given
region of the sky, over a region of photon energies, and over a period of
time.  Then the region of interest (ROI) specified by the POS and SIZE
fields would be extended to include four values rather than two.  As
details there might be special values or definitions about the
interpretation of missing fields.

The main question to be resolved is whether and how the query syntax can
select only images and spectra in the usually understood sense.  One way
might be specifying the number of elements along the energy axis; i.e. a
value of 1 is an image.  But probably a better way to make this common
distinction would be a parameter similar to INTERSECT.  A parameter such as
TYPE with values "IMAGE", "SPECTRUM", or "ANY" would place certain
requirements on the requested data content.  IMAGE would have more than one
element along each spatial dimension and only one element of energy and
time.  A spectrum would be data with multiple samples in energy.  Other
choices might restrict the request to 1D, 2D, or 3D spectral data.


Relationship with the SAO/CfA SIAP Proposal

The ideas presented here are similar in many respects to "SIAP Extension
RFC and Draft Specification, Part 1: Quantities and Coordinates" by Steve
Lowe.  The main difference is that the Lowe paper attempts to be more
general.  The approach suggested in this 4D discussion is intermediate.
Images and spectra are treated as projections of an extended
parameter space which can be handled by an extension of the SIAP
methodology.   However, the 4D proposal is to not make the extension too
general, and hence, complex.  Instead, simply add two parameters to cover
the vast majority of observational parameter space of interest to
astronomers.  Furthermore, adopt something like the degree limitation on
units for celestial coordinates to restrict the energy and time
specifications.  Transformation between units would be done by the
client interface and by the data provider.


Conclusion

This discussion suggests that observational images and spectra be treated
as aspects of a four dimensional observation model.  This assumes the
raw instrumental observations have been converted to raster sampling
along 1 to 4 axes so that spatial multiplexing or other quirks of raw
spectral data are eliminated.  Such data would be accessed by a fairly
simple extension of SIAP to a four dimensional parameter space.  There
might be a new paraemter to allow restricting requests to "images" or
"spectra" separately as well as getting information and data about holdings
which include both images and spectra in some (4D) region of interest.

From - Tue Apr 29 16:29:50 2003
X-UIDL: 3e5baf650000075f
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h3TETpWg004092
	for <dal@ivoa.net>; Tue, 29 Apr 2003 16:29:51 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h3TETp606682
	for <dal@ivoa.net>; Tue, 29 Apr 2003 16:29:51 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAvbaGcn; Tue, 29 Apr 03 16:29:50 +0200
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h3TESHNF054073
          for <dal@ivoa.net>; Tue, 29 Apr 2003 16:28:17 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id QAA05455
	for dal@ivoa.net; Tue, 29 Apr 2003 16:20:34 +0200 (MET DST)
Date: Tue, 29 Apr 2003 16:20:34 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200304291420.QAA05455@alinda.u-strasbg.fr>
To: dal@ivoa.net
Subject: Re: Call for proposals for SIAP Version 2
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h3TESHNF054073
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h3TEUFWg004145
Status:   

hello,
   a couple of days ago I sent this answer to the Call for proposals for SIAP Version 2 on the uS metadata discussion group.
maybe some of the people here do not look at their archive so I
copy my mail here
François
_______________________________________________________________

Hello Doug and other NVO actors,
   I just read the Call for proposal for SIAP version 2 and some
of the comments.
   As I told  clearly discussing with Doug and Bob
Hanish last January, we, at CDS,  want to include SIA to our
Aladin services. We plan to have a new SIA compatible test version of the
Aladin server working for the IAU GA-Hope to have a beta working for Cambridge-.At the same time the Aladin client should admit access to all the SIA services.
   When the first specification of the SIA service were annouced here 
(September 2002), we (F.Ochsenbein and I) made a few comments on this 
specification. These were important for us to be able to join the SIA world 
with full functionnality.

I)   When reading the new document posted by Doug, we find two Image
Attributes parameters which are really helpfull: the data collection
identifier and the dataset identifier. Any service hosting several surveys
or observing programs need that. Please, keep that.

II)   A large part of the discussion is about the regions of interests, and
the POS/SIZE parameters.
    For cutout and mosaic services this parameter is intended to 
be used both for the image query, ie the availability problem, and the
image size definition. 
    Isn'it possible to dissociate these two aspects ?
   
    I think there could be two ways of doing that:
   1) the image query could answer by URL templates ( parametrable)
instead of "hard coded" URL. This can allow a size parameter different
from the initial ROI size. In these conditions the initial ROI can be a cone
instead of a rectangular area.

   2) Have a format = image/METADATA output which will describe the available
images intersecting with the ROI by giving Image attributes on them , but with 
no URL. In a second step (format = fits request) the ROI should be used to 
define the size of the image.

III) More generally I think it would be usefull to have this two step 
interrogation process for other kind of image generation problems
( examples: compress or not, resample or not, mosaic or not ...)

IV) A compression status should be added in the Processing Metadata
list.


By the way as far as DAL is concerned we have recently posted on the DM and
DAL IVOA groups a first description of another acces method designed for 
the AVO prototype demonstrated last january in Jodrell Bank the "IDHA" 
metadata-tree.  I think some of you may have a look to that and give 
interesting comments.


Best regards
Francois
év

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From - Fri May  2 06:09:51 2003
X-UIDL: 3e5baf6500000800
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4249M5a012737
	for <dal@ivoa.net>; Fri, 2 May 2003 06:09:22 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4249Lh12902
	for <dal@ivoa.net>; Fri, 2 May 2003 06:09:21 +0200 (MEST)
Received: from dns.noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAc6aamz; Fri, 2 May 03 06:09:20 +0200
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 7239802 for dal@ivoa.net; Thu, 01 May 2003 21:07:48 -0700
Date: Thu, 1 May 2003 22:07:46 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: IVOA Data Access Layer <dal@ivoa.net>
Subject: DAL Working Group meeting in Cambridge
Message-ID: <Pine.LNX.4.44.0305012157180.1515-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

VO Data Access Layer (DAL) Working Group
IVOA, Cambridge, UK  May 12-16 2003


Hi Folks -

We will have the kick-off meeting of the IVOA Data Access Layer (DAL)
working group on Monday May 12 at the IVOA Interoperability meeting in
Cambridge.  The initial discussion will be followed by smaller breakout
meetings throughout the week, with a wrap-up discussion in plenary session
on Friday morning.

The primary purpose of the DAL working group will be to define, over the
next year or so, the initial set of IVOA standards for VO science data
access.  In the Cambridge meeting we will need to clarify the scope of our
working group and develop a roadmap of our activities for the next year.
This will include identifying what data access standards are needed, how
these will interoperate with each other, and how these will integrate
with the infrastructure being developed by the other working groups
(registry, UCDs, data models, VOTable, etc.).  A special topic, possibly
for a subgroup, will be to discuss what should be included in the second,
"IVOA" version of the simple image access protocol due out this summer.

Our first item of business is to prepare an agenda for the meeting.
***Anyone who is interested in presenting any material at the meeting
should contact the WG organizers immediately.***  Please contact either
myself (dtody@nrao.edu) or Markus Dolensky (Markus.Dolensky@eso.org),
who is helping to organize the working group.  We can't promise anything
at this point about presentations (it will depend upon the final agenda
and the time available) but we do want to benefit from our collective
experiences in preparing these standards.  Suggestions for agenda items
or topics are also welcome.

	- Doug


To help identify the areas where work is needed some thoughts on the
scope of the VO data access layer follow.


Scope of VO Data Access Layer

The scope of the VO Data Access Layer includes the services and protocols
used to access remote science data via the VO, as well as the software
used to implement data access services.  Ultimately this will include
advanced capabilities such as data subsetting, data model mediation,
and server-side analysis, i.e., for grid computing.  We must also include
some client-side software to demonstrate an end-user analysis capability
and perform end-to-end testing and integration.  Ultimately most analysis
software will come from the user community, not from VO.  DAL builds upon
and integrates other VO technology for metadata, data models, data formats,
registries, and queries.

The science data dealt with by the DAL potentially includes all of the
following:

    catalogs
        e.g., object catalogs

	Catalog analysis is a fundamental VO capability which is beyond
	the scope of mere data access, but at the DAL level catalog
	and image/spectra access are often performed together.

    images
        e.g., 2D sky images
    data cubes
        e.g., 2D sky images with a spectral axis
    spectra, SEDs
        mainly 1D spectra
        2D/longslit spectra? (maybe not right away)
    time series
        e.g., time-resolved photometry
        spectrally-resolved light curves
        synoptic imagery (e.g., all-sky camera, synoptic surveys)

    event list (photon counting) data
    visibility data (interferometry)

The highest priority goes to object catalogs and 2D sky images, for which
prototype data access services are already available.  Spectral data cubes
are probably best treated as a general type of image.  Next in priority
are spectra, especially simple 1D spectra; spectra are a high priority for
the next phase of DAL development.  Time series data is less common but is
similar to 1D spectra and could possibly benefit from a similar approach.
It would be useful to integrate event list data and visibility data into
the VO, although our expectation is that most VO users will be interested
in images produced from such data rather than the original data (image
generation may need to be on-the-fly since there is in general no one
best way to produce images from event data or UV data).

The highest priority for IVOA data access standards is probably in the area
of standard data access protocols - this is what we should emphasize in
the first year.  Protocols are, or should be, implementation-independent
and hence are one of these easiest software elements to standardize.
As the VO software and infrastructure becomes more complicated it will
become increasingly important to provide some reusable VO framework-level
software to simplify the job of those putting up services or writing
client-side applications.  Finally as we move to grid computing it will
become necessary to dynamically deploy computational components on any
grid-enabled computational resource.  For this to be feasible we will need
some interoperability standards in the areas of computational frameworks
and components.

From - Fri May  2 12:49:51 2003
X-UIDL: 3e5baf6500000808
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h42Ao25a029763
	for <dal@ivoa.net>; Fri, 2 May 2003 12:50:02 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h42Ao1O00915
	for <dal@ivoa.net>; Fri, 2 May 2003 12:50:01 +0200 (MEST)
Received: from curlew.cs.man.ac.uk(130.88.13.7) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAynaqYb; Fri, 2 May 03 12:50:00 +0200
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.14)
	id 19BY71-0009It-9V
	for dal@ivoa.net; Fri, 02 May 2003 11:49:55 +0100
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 19BY7S-0000PT-00
	for dal@ivoa.net; Fri, 02 May 2003 11:50:22 +0100
Date: Fri, 2 May 2003 11:49:45 +0100 (BST)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: dal@ivoa.net
Subject: Re: spectral data 
Message-ID: <Pine.GSO.4.53.0305021118370.16953@adikia>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -12.9 (------------)
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *19BY71-0009It-9V*ydiqMFBNTGg*
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   


In response to Frank Valdes' comprehensive and very readable posting,
> Incorporating spectra in the Next Phase of the VO ..
I think there are two more things which flow out of this:
- errors
- conversions and conventions

These are covered in e.g. Greisen et al 2002 Representations of spectral
coordinates in FITS - is this published yet?

and we need to think about two sorts of conversion
1) Accuracy needed for answering queries - here we need to know the
bandpass shape etc. etc. if the user wants high accuracy.
2) Accuracy for Registry Resource metadata and crude conversions -
we can probably ignor filter/instrumetn-specific and other details.  In
other cases also, e.g. line ratios from a single dataset, useful results
can be obtained without all the information one would have in an ideal
world.

I take issue with one comment:

> However, the 4D proposal is to not make the extension too general, and
> hence, complex. Instead, simply add two parameters to cover the vast
> majority of observational parameter space of interest to astronomers.

Unfortunately - or fortunately - that is a very dangerous thing to say.
Polarization is one example of extra axes in image data, let alone other
sorts of data like time-series along moving coordinates or visibility
data.

Just one example in the image domain: Monitioring of SiO maser emission.
Experiments currently published produce:
Multiple epochs of RA-Dec-Frequency datacubes  (4 axes)
in Stokes I Q U V			       (another 4 axes?)
in 2 or more lines of SiO	               (another >2 axes?)

I am not suggesting we start by figuring out how to represent this but we
need to be able to easily add dimensions, and I think we need to tackle
polarization after we have a working consensus on spectral coordinates.

In addition, some data use an extra dimension or dimensions for
uncertainties, masks etc.


Regarding Ivo Busko's document on Generic Spectral Data Structures, I
guess this is just for handling certain types of data? as it does not seem
to cover the 3 or 4 D cases, e.g. datacubes, described by Frank Valdes.
This is not a criticism, as I am sure Specview is very good in its domain,
but it will not meet all the near future needs of the VO.

thanks
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).

From - Fri May  2 16:44:51 2003
X-UIDL: 3e5baf650000081c
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h42EhU5a025974
	for <dal@ivoa.net>; Fri, 2 May 2003 16:43:30 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h42EhTx27923
	for <dal@ivoa.net>; Fri, 2 May 2003 16:43:29 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAjfayH2; Fri, 2 May 03 16:43:28 +0200
Received: from cfa.harvard.edu (pioneer [131.142.184.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h42EZwVB026387;
	Fri, 2 May 2003 10:35:58 -0400 (EDT)
Message-ID: <3EB2824E.1030908@cfa.harvard.edu>
Date: Fri, 02 May 2003 10:35:58 -0400
From: Steve Lowe <slowe@cfa.harvard.edu>
Organization: SAO / CfA
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anita Richards <amsr@jb.man.ac.uk>
CC: dal@ivoa.net
Subject: Re: spectral data
References: <Pine.GSO.4.53.0305021118370.16953@adikia>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Anita Richards wrote:

>In response to Frank Valdes' comprehensive and very readable posting,
>  
>
>>However, the 4D proposal is to not make the extension too general, and
>>hence, complex. Instead, simply add two parameters to cover the vast
>>majority of observational parameter space of interest to astronomers.
>>    
>>
>
>Unfortunately - or fortunately - that is a very dangerous thing to say.
>Polarization is one example of extra axes in image data, let alone other
>sorts of data like time-series along moving coordinates or visibility
>data.
>
>Just one example in the image domain: Monitioring of SiO maser emission.
>Experiments currently published produce:
>Multiple epochs of RA-Dec-Frequency datacubes  (4 axes)
>in Stokes I Q U V			       (another 4 axes?)
>in 2 or more lines of SiO	               (another >2 axes?)
>  
>
I'd be interested on your comments on the SAO/CfA proposal on SIAP, 
which is in the us-vo data repository. The direct link is:
http://bill.cacr.caltech.edu/cfdocs/usvo-pubs/files/ACFE3.pdf

A key element in the proposal is that services have a way of enumerating 
the data axes that can be used in a query, both for defining the search 
region and for requesting a specific type of data product. That way a 
service can be as limited or as general as needed for the data 
collection it is serving.

The document is only the first part of the plan we are working on, so I 
apologize if it is not transparent on some points. We're trying to flesh 
out the implications and develop a more complete proposal. Also, we're 
not totally committed to some of the syntactic choices presented, and, 
indeed, you'll see that in some places alternatives are presented.

Any comments you have will be appreciated.

Regards,
Steve


-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe@cfa.harvard.edu
1-617-496-1661



From - Sat May 10 16:25:31 2003
X-UIDL: 3e5baf6500000910
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <owner-metadata@us-vo.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h49FABOl015152
	for <mdolensk@eso.org>; Fri, 9 May 2003 17:10:11 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h49FABG13873
	for <mdolensk@eso.org>; Fri, 9 May 2003 17:10:11 +0200 (MEST)
Received: from mercury.cacr.caltech.edu(131.215.145.175) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAuqaagB; Fri, 9 May 03 17:10:09 +0200
Received: from mercury.cacr.caltech.edu (localhost [127.0.0.1])
	by mercury.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.3) with ESMTP id h49El59B015867
	for <metadata-list@mercury.cacr.caltech.edu>; Fri, 9 May 2003 07:47:05 -0700
Received: (from majordomo@localhost)
	by mercury.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.3) id h49El5An015865
	for metadata-list; Fri, 9 May 2003 07:47:05 -0700
X-Authentication-Warning: mercury.cacr.caltech.edu: majordomo set sender to owner-metadata@us-vo.org using -f
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by mercury.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.3) with ESMTP id h49El39B015862
	for <metadata@us-vo.org>; Fri, 9 May 2003 07:47:04 -0700
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.6p2/jtpda-5.4) with ESMTP id h49F8SW4046828
          ; Fri, 9 May 2003 17:08:28 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id RAA18629;
	Fri, 9 May 2003 17:00:37 +0200 (MET DST)
Date: Fri, 9 May 2003 17:00:37 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200305091500.RAA18629@alinda.u-strasbg.fr>
To: dal@ivoa.net, metadata@us-vo.org
Subject: Beta version of SIAP/Aladin server
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-metadata@us-vo.org
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.cacr.caltech.edu id h49El59B015867
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h49FABOl015152
Status:   

Hello,
   In order to be able to discuss SIAP 2 next monday we implemented two beta 
versions of a test aladin server speaking "SIAP 1". one is for a cutout service. The other one for an atlas service.

   the test server has the same data than the AVO/prototype IDHA server.
Specifically around the LMC and the Chandra deep field south.

   Here are the URL you can test
http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?mode=siap_atlas&out=qualifier&POS=80.89416667%2C-69.75611111&SIZE=0.2&FORMAT=image%2Ffits

http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?mode=siap_cutout&out=qualifier&POS=053.11629%2C-27.808&SIZE=0.2&FORMAT=image%2Ffits&INTERSECT=CENTER

You can slightly change the POS and SIZE of course ...

http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?mode=xml_votable_idha&out=qualifier&position=053.11629+-27.808&radius=0.2

will give you the IDHA metadata tree for the same regions.

See some of you on Monday !!!
Regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From - Sat May 10 16:25:32 2003
X-UIDL: 3e5baf650000091c
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h49HCROl026506
	for <dal@ivoa.net>; Fri, 9 May 2003 19:12:27 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h49HCRP20318
	for <dal@ivoa.net>; Fri, 9 May 2003 19:12:27 +0200 (MEST)
Received: from noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAARBaGRN; Fri, 9 May 03 19:12:26 +0200
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 7305928; Fri, 09 May 2003 10:11:10 -0700
Date: Fri, 9 May 2003 11:11:03 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
cc: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: Beta version of SIAP/Aladin server
In-Reply-To: <200305091500.RAA18629@alinda.u-strasbg.fr>
Message-ID: <Pine.LNX.4.44.0305091105180.18326-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mercury.hq.eso.org id h49HCXOl026522
Status:   

Hi Francois -

Congratulations - it is great to see another service up!  This should help
tell us what the issues are for a large site like CDS.

I just tried out the service (it seemed very fast and responsive by the way)
and have only a couple of quick comments:

    o	Although it probably doesn't matter for testing purposes, it would
    	be nice to have the full image WCS in the metadata that is returned.
	(There is enough information there now though to estimate the WCS).

    o	To test getting an image I use wget with the given access-reference.
    	When I try this I get back a little text file with an error message
	saying 'field not found'.

Cheers.  See you on Monday.

	- Doug



On Fri, 9 May 2003, Francois Bonnarel wrote:

> Hello,
>    In order to be able to discuss SIAP 2 next monday we implemented two beta 
> versions of a test aladin server speaking "SIAP 1". one is for a cutout service. The other one for an atlas service.
> 
>    the test server has the same data than the AVO/prototype IDHA server.
> Specifically around the LMC and the Chandra deep field south.
> 
>    Here are the URL you can test
> http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?mode=siap_atlas&out=qualifier&POS=80.89416667%2C-69.75611111&SIZE=0.2&FORMAT=image%2Ffits
> 
> http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?mode=siap_cutout&out=qualifier&POS=053.11629%2C-27.808&SIZE=0.2&FORMAT=image%2Ffits&INTERSECT=CENTER
> 
> You can slightly change the POS and SIZE of course ...
> 
> http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?mode=xml_votable_idha&out=qualifier&position=053.11629+-27.808&radius=0.2
> 
> will give you the IDHA metadata tree for the same regions.
> 
> See some of you on Monday !!!
> Regards
> François
> 
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
> 
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
> ---------------------------------------------------------------------
> 
> 


From - Sat May 10 16:25:32 2003
X-UIDL: 3e5baf6500000927
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4A06LqC022248
	for <dal@ivoa.net>; Sat, 10 May 2003 02:06:21 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4A06Lc06292
	for <dal@ivoa.net>; Sat, 10 May 2003 02:06:21 +0200 (MEST)
Received: from noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAgpaysm; Sat, 10 May 03 02:06:19 +0200
Received: from puppis.tuc.noao.edu ([140.252.4.30] verified)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 7310500 for dal@ivoa.net; Fri, 09 May 2003 17:05:03 -0700
Received: (from valdes@localhost)
	by puppis.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) id RAA15792
	for dal@ivoa.net; Fri, 9 May 2003 17:05:03 -0700 (MST)
Date: Fri, 9 May 2003 17:05:03 -0700 (MST)
From: Frank Valdes <valdes@noao.edu>
Message-Id: <200305100005.RAA15792@puppis.tuc.noao.edu>
To: dal@ivoa.net
Subject: A Virtual Observatory Data Model
X-Sun-Charset: US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

                        [NOAO Data Products Program]

                      A Virtual Observatory Data Model

                              Francisco Valdes
                              fvaldes@noao.edu
                                May 9, 2003

COVER LETTER

The following (also http://iraf.noao.edu/projects/vo/dal/datamodel.html) is
a contribution for the data model discussions at the working groups meeting
next week in Cambridge. It is an extension of some earlier ideas ( [1] , [2]
) on including celestial coordinates in the WCS for 1D and 2D spectra and on
the question about whether accessing spectra and images in the prototype VO
framework requires different protocols. Because of the deadline imposed by
the meeting the discussion is abbreviated in some areas. My hope is
emphasize the general philosophy and approach. There are some important
ideas which I support in the Spectral Data Models draft from Jonathan
McDowell and Steve Lowe but there are some philosophical differences which I
wanted to offer. Primarily the ideas of treating images and spectra as
projections of a more general class and simplifying as much as possible by
limiting VO data to "calibrated" forms which don't require complex metadata
to interpret.

Because I decided it was more valuable to try and build a consistent
discussion from my perspective I did not have time to also critique the
McDowell and Lowe concepts. But it makes sense that before doing that one
really needs to reach concensus on whether to treat spectra of various
dimensions separately or whether to work towards an integrated
spectrum/image data model.

Good luck in the meetings. I'm sorry I can't be there.

Frank Valdes

   * [1] Spectral WCS Conventions
     About FITS WCS and how 1D and 2D spectra can include celestial
     coordinates.
   * [2] Incorporating Spectra in the Next Phase of the Virtual Observatory

1. What is a virtual observatory data model?

The first hurtle to overcome in defining virtual observatory (VO) data
models is to understand what they are and what they are not. In the
discussion given here a VO data model is the SIMPLEST abstraction of
physically calibrated, wavelength regime and detector technology independent
astronomical data.

We emphasize simplest because a key part of the VO concept is that users,
called VO observers, should not need to be experts in every regime of
astronomy and instead only be educated astrophysicists. The science done by
VO observers generally involves data from various telescopes and various
energy subdisciplines. The reason for striving towards the simplest
description is to allow concensus and interoperability between a wide
variety of data providers.

The other side of the question, which should be a mantra of sorts, is:

    "VO data models are not FITS or file formats"
    "VO data models are not archived data"
    "VO data models are not instrumental data"

2. Celestial Sphere Binned Photon Observations - 4DBIN

This document defines a broad class of astronomical data called "Celestial
Sphere Binned Photon Observations". Note that the detailed definition of the
class identified by this label is more specific than the literal
interpretation of the words. The definition of the class flows from the name
as follows.

     Celestial Sphere
          Restricts the class to data about the two dimensional
          celestial sphere. There are two spatial parameters specifying
          the longitude and a latitude in some specified celestial
          system.
     Photon
          Restricts the class to data about the photon energies as
          described by an energy parameter.
     Binned
          Restricts the class to data about the number of photons
          arriving over finite regions, called bins, of the parameter
          domain. A way to look at this is that photon events are
          indistinguishable within a bin. A further restriction is that
          the bins are rectangular so they may be described by a center
          and width in each parameter.
     Observations
          Restricts the class to data about photons over a time
          described by time parameter. Observation evokes the idea of
          detecting photons over an integration period, though
          simulation and model results can be cast into simulated
          observations.

This definition of the class has four parameters; celestial position,
energy, and time. This forms a continuous space or domain which is divided
into a set of bins that are not necessarily uniformly distributed or of
equal size. Each bin is associated with the number of photons it contains.
The number of photons may be expressed in various ways such as number,
energy, and flux.

This class may be thought of data obtain through the following process.
Photons of various energies are detected as a function of time coming from
points on the sky. Each photon is tagged by four numbers from a four
dimensional continuous space. The numbers are a latitude and longitude on
the celestial sphere from which the photon arrives, the energy of the
photon, and the time. The continuous space is divided into a set of discrete
regions or bins which are indexed in some fashion. The photons are counted
in each bin. The details of the continuous energy, position, and time
parameters are lost and only the bin index and bin counts are retained.

This definition makes a notable distinction between the measured quantity,
the photons, and the sampling, the bins. This distinction is often confused
or lost. The photons, sometimes thought of as the "z" axis in an image, is
the scientific content which is conveyed in standard physical units. The
sampling or binning is variable and dependent on the way the data was
obtained. The VO infrastructure or the data providers may "convert" units
for the photon values and "resample" the bins at the request of the VO
observer.

To identify data which falls into this class we define a top level tag

        VOCLASS = 4DBIN

2.1 What is the difference between VO data and observational data?

A key aspect of virtual observatory photon binned data is that the primary
bin values be calibrated to standard physically meaningful units. There are
two important reasons for this. One is to allow VO observers to easily
intercompare data with only simple physical unit conversions. The other is
to simplify the data model and limit metadata which must be supplied to
allow meaningful interpretation.

This does provide a small burden on the data providers above what has been
typical. For instance, optical imaging often provides data in digital units
with the conversion to photons implicit in a gain and a magnitude zeropoint.
For VO data the data provider does the gain multiplication and conversion of
the magnitude system to photon based units so that non-optical astronomers
don't need to understand the detector technology, many of the ideas of
magnitudes, and the metadata doesn't need to include a gain and magnitude
zeropoint.

In order to provide a "caveat emptor" option to the VO observers and data
providers, a top-level metadata declaration is whether the primary data
values meet the VO standard for this class:

        4DBIN.CALIBRATED = [yes|no|relative]

By asserting "no" the data may be useful but would require the VO observer
to calibrate it themselves in some way. The "relative" calibration is a way
to assert that the data is proportional to photon counts and that the
response to photon fluxes is independent of position (after taking
differences in bin sizes into account). Therefore, relative comparison
between different bins is scientifically meaningful even though an absolute
calibration is not defined.

Note that the first sentence of this section refers to the "primary photon
bin values". The reason for this is that the observational and calibration
characteristics appear in the ancillary data and metadata. This is primarily
contained in the uncertainties but some other useful information may be
provided in exposure maps and data quality flags.

2.2 What is an image and a spectrum?

In as much as astronomers define and distinguish between "images" and
"spectra", an image is a subclass with only a single energy bin, a single
time bin, and multiple bins in both spatial parameters. The energy bin is
often fairly wide but not always. A spectrum also has only a single time
bin, but has more than one energy bin, and one or more spatial bins.

Astronomers also typically discriminate between spectra having a single
spatial bin, called a "one-dimensional spectrum", and multiple spatial bins,
often called a "data cube". The special case of spatial bins restricted to a
curve on the celestial sphere is called a "slit spectrum".

In this document there is no distinction made between spectra and images.
However, one could choose to subclass the metadata concepts. A subclass
means using implicit and explicit conventions and defaults. The subclasses
might be:

        VOCLASS = 4DBIN.IMAGE
        VOCLASS = 4DBIN.1DSPECTRUM
        VOCLASS = 4DBIN.SLITSPECTRUM
        VOCLASS = 4DBIN.DATACUBE

3. Metadata

Data from 4DBIN Class fundamentally consists of a set of numbers related to
photon counts. To make sense of this set of numbers requires metadata or
conventions which describe the relationship between photon counts and the
bin value, define the bins, the uncertainties in the values, and associated
attributes.

As a thought experiment, which we use to identify the metadata through a use
case, suppose one is given the set of numbers {0,6,7,2,5,3,1,4}. What do we
need to understand something about the photons observed on the sky? Along
these lines the minimal metadata necessary should be separated from optional
metadata. Here we suggest the minimal description is provided by section 3.1
on the bin geometry and section 3.2 on the bin values.

First we need a top level piece of metadata defining the class and
conventions. This type of metadata is sometimes associated with a name, such
as FITS (with SIMPLE=T). For this document we define this metadata class
domain

        VOCLASS = 4DBIN

3.1 Bin Geometry

The metadata for the bin geometry describes the mapping from the continuous
four dimensional photon parameter space to the discrete indexed bins. As
noted in section 2, the bins are required to be described by a center and
width along each of the four parameter dimensions. This constitutes the bin
geometry.

The first thing we need is a definition for the indexing of the data bin
values. There are two straightforward ways to do this. One is to use the
ordinal of the data value set. The other is to arrange the values into an
array. For the 4DBIN class the array is required to be four dimensional.

        4DBIN.INDEXING = ordinal
        4DBIN.INDEXING = array(N1,N2,N3,N4)

3.1.1 Ordinal or tabular indexing

The first method is completely general while the second requires the number
of data values to be the product of the array dimensions. At this point the
two indexing schemes seem pretty much the same. The distinction comes in how
the indices are used to map to the bin geometries in the four dimensional
parameter space. In practice, the ordinal indexing is used with a table and
the array is used for gridded bins.

In the ordinal indexing the metadata includes a table of bin geometry
values. The table is a set of numbers ordered such that each sequential set
of eight values define a line and the line number corresponds to the data
value with matching ordinal. For example, the first eight numbers apply to
the first data value, the second eight to the second data value, and so
forth. The eight values are the bin centers in longitude, latitude, energy,
and time followed by bin widths.

In the simple 1D spectrum example we might have

  0 : 12h10m15s 32d15m10s 4001A 2003-05-07T12:10:15 1arcsec 1arcsec 1A 300s
  6 : 12h10m15s 32d15m10s 4002A 2003-05-07T12:10:15 1arcsec 1arcsec 1A 300s

3.1.2 Array or raster indexing

For the array indexing we use a metadata description along the lines of the
FITS WCS. This is a complex description which we only touch on here with
attention to the restrictions imposed by the 4DBIN class. The metadata
components would include many of the basic elements of the FITS WCS
metadata. Besides the actual formalism for evaluating the bin centers and
widths another key piece of metadata is the units of the four parameters.

The main restriction on the FITS WCS formalism as it applies to the 4DBIN
class is that the axes ordering is required to be latitude, longitude,
energy, and time and so the FITS WCS is always a WCSDIM of 4. The FITS WCS
does not currently explicitly define time coordinates. But for the main data
types of interest, images and spectra with a single time bin, we simply use
a linear WCS.

The bin centers are a direct analog to the pixel centers in the FITS WCS.
There is a linear mapping from the array index to an intermediate WCS
coordinate. There is potentially a distortion transformation to an ideal
intermediate coordinate. For calibrated data typical of the VO this should
not be required except possibly to describe the path of a slit spectrum on
the sky. Finally there is a projection or standard non-linear transformation
to the final coordinates.

One new feature of the FITS WCS formalism is use of a lookup table. This
allows for bin centers which are not uniformly arrayed in the parameter
space. It can provide similar information to the ordinal description.

The concept of bin widths is only implicit in the FITS WCS formalism. For
the array indexing metadata model defined here, the bin widths are computed
from the WCS using the idea that the WCS functions are continuous in the
index space. So the bin edges are computed by adding and subtracting
one-half to the integer indices and evaluating the parameter value at those
points. The WCS formalism is more general than simple rectangular bins so
this computation is done by varying only the index of one parameter. The
width of the bin is average difference from the integer index center and the
two half index values.

3.2 Bin Values

Section 2.1 declares that calibrated 4DBIN data be in certain physical units
directly related to the photons and the bin sizes. The primary metadata for
the bin values is then the units. For example,

    4DBIN.VALUES.UNITS = ergs/s/cm^2/A
    4DBIN.VALUES.UNITS = photons
    4DBIN.VALUES.UNITS = Jy

The definition of the allowed units also needs to provide standards such as
calibrations to above the atmosphere.

When there is a significant variation in the detection of photons across an
energy bin, such as occurs with a filter in a broadband image, the
calibration must be referenced to the filter system.

    4DBIN.FILTER = Johnson(B)

Background contributions need to be described by primary metadata.

    4DBIN.VALUES.BACKGROUND = Subtracted using nearby simultaneous observations
    4DBIN.VALUES.BACKGROUND = Subtracted by CCD shuffling
    4DBIN.VALUES.BACKGROUND = None subtracted

3.4 Uncertainties

For identification purposes, such as finding sources or redshifts, and when
the magnitude of the signal is high, such as continuum shapes over decades
of energy, the uncertainties about the data bin values may not be important.
In other words, there a a number of uses for calibrated VO data that just
depend on the data units and the the binning.

But for detailed measurements where detection and instrumental effects are
important, a significant piece of metadata are the uncertainties. There are
two approaches which might be provided by the data model. The more rigorous
approach would be to give statistical information about each bin (possibly
including covariances).

The statistical description of the uncertainties implicitly carries
information about exposure times, rejected data in combined observations,
variable sensitivities, and so on. Other attribute metadata may explicitly
provide the means to separate these implicit contributions to the total
uncertainties.

The other is to provide a functional description. This is only really useful
if the data is relatively homogeneous so that variable DQE, bin sizes, and
backgrounds are not present. A typical model describes the variances as a
function of the data values. For instance,

        V = A + B N ...

where N is the binned photon number.

3.5 Attributes

This section on attributes is a catch-all for all the rest of the metadata.
This is all to be defined. However a quick list of common useful attributes
is given below.

     label/title
          a label or title provided by the observer
     object ID
          a standard object id
     instrument
          details of the telescope and instrumentation
     conditions
          information about the observing conditions
     calibrations
          details of the calibrations

     data quality
          a table of data quality indicators for:
             o uncalibrated bins due to vignetting or masking
             o poorly calibrated bins
     exposure map
          a table of effective exposure times
     exposure filter
          a table describing chopping, shuffling, sequences of combined
          exposures, etc. This is a filter function for the time
          dimension of a bin.

From - Sat May 10 16:25:32 2003
X-UIDL: 3e5baf650000092b
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4A8JnqC027766
	for <dal@ivoa.net>; Sat, 10 May 2003 10:19:49 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4A8JnT16207
	for <dal@ivoa.net>; Sat, 10 May 2003 10:19:49 +0200 (MEST)
Received: from noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAHYaWPF; Sat, 10 May 03 10:19:48 +0200
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 7312363 for dal@ivoa.net; Sat, 10 May 2003 01:18:23 -0700
Date: Sat, 10 May 2003 02:18:10 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: DAL Working Group meeting in Cambridge
In-Reply-To: <Pine.LNX.4.44.0305012157180.1515-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.44.0305100213440.27149-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Folks -

A list of reading materials and an updated agenda for the DAL working
group has been posted on the IVOA Wiki at

    http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003DAL

See you all in Cambridge next week.

	- Doug


On Thu, 1 May 2003, Doug Tody wrote:

> VO Data Access Layer (DAL) Working Group
> IVOA, Cambridge, UK  May 12-16 2003
> 
> 
> Hi Folks -
> 
> We will have the kick-off meeting of the IVOA Data Access Layer (DAL)
> working group on Monday May 12 at the IVOA Interoperability meeting in
> Cambridge.  The initial discussion will be followed by smaller breakout
> meetings throughout the week, with a wrap-up discussion in plenary session
> on Friday morning.
> 
> The primary purpose of the DAL working group will be to define, over the
> next year or so, the initial set of IVOA standards for VO science data
> access.  In the Cambridge meeting we will need to clarify the scope of our
> working group and develop a roadmap of our activities for the next year.
> This will include identifying what data access standards are needed, how
> these will interoperate with each other, and how these will integrate
> with the infrastructure being developed by the other working groups
> (registry, UCDs, data models, VOTable, etc.).  A special topic, possibly
> for a subgroup, will be to discuss what should be included in the second,
> "IVOA" version of the simple image access protocol due out this summer.
> 
> Our first item of business is to prepare an agenda for the meeting.
> ***Anyone who is interested in presenting any material at the meeting
> should contact the WG organizers immediately.***  Please contact either
> myself (dtody@nrao.edu) or Markus Dolensky (Markus.Dolensky@eso.org),
> who is helping to organize the working group.  We can't promise anything
> at this point about presentations (it will depend upon the final agenda
> and the time available) but we do want to benefit from our collective
> experiences in preparing these standards.  Suggestions for agenda items
> or topics are also welcome.
> 
> 	- Doug
> 
> 
> To help identify the areas where work is needed some thoughts on the
> scope of the VO data access layer follow.
> 
> 
> Scope of VO Data Access Layer
> 
> The scope of the VO Data Access Layer includes the services and protocols
> used to access remote science data via the VO, as well as the software
> used to implement data access services.  Ultimately this will include
> advanced capabilities such as data subsetting, data model mediation,
> and server-side analysis, i.e., for grid computing.  We must also include
> some client-side software to demonstrate an end-user analysis capability
> and perform end-to-end testing and integration.  Ultimately most analysis
> software will come from the user community, not from VO.  DAL builds upon
> and integrates other VO technology for metadata, data models, data formats,
> registries, and queries.
> 
> The science data dealt with by the DAL potentially includes all of the
> following:
> 
>     catalogs
>         e.g., object catalogs
> 
> 	Catalog analysis is a fundamental VO capability which is beyond
> 	the scope of mere data access, but at the DAL level catalog
> 	and image/spectra access are often performed together.
> 
>     images
>         e.g., 2D sky images
>     data cubes
>         e.g., 2D sky images with a spectral axis
>     spectra, SEDs
>         mainly 1D spectra
>         2D/longslit spectra? (maybe not right away)
>     time series
>         e.g., time-resolved photometry
>         spectrally-resolved light curves
>         synoptic imagery (e.g., all-sky camera, synoptic surveys)
> 
>     event list (photon counting) data
>     visibility data (interferometry)
> 
> The highest priority goes to object catalogs and 2D sky images, for which
> prototype data access services are already available.  Spectral data cubes
> are probably best treated as a general type of image.  Next in priority
> are spectra, especially simple 1D spectra; spectra are a high priority for
> the next phase of DAL development.  Time series data is less common but is
> similar to 1D spectra and could possibly benefit from a similar approach.
> It would be useful to integrate event list data and visibility data into
> the VO, although our expectation is that most VO users will be interested
> in images produced from such data rather than the original data (image
> generation may need to be on-the-fly since there is in general no one
> best way to produce images from event data or UV data).
> 
> The highest priority for IVOA data access standards is probably in the area
> of standard data access protocols - this is what we should emphasize in
> the first year.  Protocols are, or should be, implementation-independent
> and hence are one of these easiest software elements to standardize.
> As the VO software and infrastructure becomes more complicated it will
> become increasingly important to provide some reusable VO framework-level
> software to simplify the job of those putting up services or writing
> client-side applications.  Finally as we move to grid computing it will
> become necessary to dynamically deploy computational components on any
> grid-enabled computational resource.  For this to be feasible we will need
> some interoperability standards in the areas of computational frameworks
> and components.
> 
> 

From - Mon May 12 17:55:03 2003
X-UIDL: 3e5baf6500000957
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4CFqPTA001469
	for <dal@ivoa.net>; Mon, 12 May 2003 17:52:35 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4CFqOv09680
	for <dal@ivoa.net>; Mon, 12 May 2003 17:52:24 +0200 (MEST)
Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAf6a45s; Mon, 12 May 03 17:52:22 +0200
Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136])
	by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h4CFpHAV029384;
	Mon, 12 May 2003 11:51:17 -0400
Message-ID: <3EBFC349.3000305@gsfc.nasa.gov>
Date: Mon, 12 May 2003 11:52:41 -0400
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
Reply-To: edward.j.shaya.1@gsfc.nasa.gov
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Frank Valdes <valdes@noao.edu>
CC: dal@ivoa.net
Subject: Re: A Virtual Observatory Data Model
References: <200305100005.RAA15792@puppis.tuc.noao.edu>
In-Reply-To: <200305100005.RAA15792@puppis.tuc.noao.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Frank,
    I think this is the right direction.  I just want to add a few items 
that the scientist, even the non-instrument scientist, needs to have but 
I think are missed here.
1. resolution - Although photons fall into bins or pixels, the 
resolution tells one the probability that a photon in a particular bin 
could have fallen into a nearby bin.
2. crosstalk - There is some tendency for the liberated electrons to 
leak to the adjacent pixel.  So, even when pixel size is much larger the 
spatial resolution the photon has a distinct probability of registering 
in the wrong pixel.

I believe that time-series data is also covered by this model.
VOCLASS = 4DBIN.TIMESERIES

Finally, what do we do about observations on a moving target (asteroid, 
planet, comet, perhaps even high proper motion star)?   I think there 
should be an option to substitute an object name for the two spatial 
coordinates (unless you want to define a path on the celestial sphere).

Ed


Frank Valdes wrote:

>                        [NOAO Data Products Program]
>
>                      A Virtual Observatory Data Model
>
>                              Francisco Valdes
>                              fvaldes@noao.edu
>                                May 9, 2003
>
>COVER LETTER
>
>The following (also http://iraf.noao.edu/projects/vo/dal/datamodel.html) is
>a contribution for the data model discussions at the working groups meeting
>next week in Cambridge. It is an extension of some earlier ideas ( [1] , [2]
>) on including celestial coordinates in the WCS for 1D and 2D spectra and on
>the question about whether accessing spectra and images in the prototype VO
>framework requires different protocols. Because of the deadline imposed by
>the meeting the discussion is abbreviated in some areas. My hope is
>emphasize the general philosophy and approach. There are some important
>ideas which I support in the Spectral Data Models draft from Jonathan
>McDowell and Steve Lowe but there are some philosophical differences which I
>wanted to offer. Primarily the ideas of treating images and spectra as
>projections of a more general class and simplifying as much as possible by
>limiting VO data to "calibrated" forms which don't require complex metadata
>to interpret.
>
>Because I decided it was more valuable to try and build a consistent
>discussion from my perspective I did not have time to also critique the
>McDowell and Lowe concepts. But it makes sense that before doing that one
>really needs to reach concensus on whether to treat spectra of various
>dimensions separately or whether to work towards an integrated
>spectrum/image data model.
>
>Good luck in the meetings. I'm sorry I can't be there.
>
>Frank Valdes
>
>   * [1] Spectral WCS Conventions
>     About FITS WCS and how 1D and 2D spectra can include celestial
>     coordinates.
>   * [2] Incorporating Spectra in the Next Phase of the Virtual Observatory
>
>1. What is a virtual observatory data model?
>
>The first hurtle to overcome in defining virtual observatory (VO) data
>models is to understand what they are and what they are not. In the
>discussion given here a VO data model is the SIMPLEST abstraction of
>physically calibrated, wavelength regime and detector technology independent
>astronomical data.
>
>We emphasize simplest because a key part of the VO concept is that users,
>called VO observers, should not need to be experts in every regime of
>astronomy and instead only be educated astrophysicists. The science done by
>VO observers generally involves data from various telescopes and various
>energy subdisciplines. The reason for striving towards the simplest
>description is to allow concensus and interoperability between a wide
>variety of data providers.
>
>The other side of the question, which should be a mantra of sorts, is:
>
>    "VO data models are not FITS or file formats"
>    "VO data models are not archived data"
>    "VO data models are not instrumental data"
>
>2. Celestial Sphere Binned Photon Observations - 4DBIN
>
>This document defines a broad class of astronomical data called "Celestial
>Sphere Binned Photon Observations". Note that the detailed definition of the
>class identified by this label is more specific than the literal
>interpretation of the words. The definition of the class flows from the name
>as follows.
>
>     Celestial Sphere
>          Restricts the class to data about the two dimensional
>          celestial sphere. There are two spatial parameters specifying
>          the longitude and a latitude in some specified celestial
>          system.
>     Photon
>          Restricts the class to data about the photon energies as
>          described by an energy parameter.
>     Binned
>          Restricts the class to data about the number of photons
>          arriving over finite regions, called bins, of the parameter
>          domain. A way to look at this is that photon events are
>          indistinguishable within a bin. A further restriction is that
>          the bins are rectangular so they may be described by a center
>          and width in each parameter.
>     Observations
>          Restricts the class to data about photons over a time
>          described by time parameter. Observation evokes the idea of
>          detecting photons over an integration period, though
>          simulation and model results can be cast into simulated
>          observations.
>
>This definition of the class has four parameters; celestial position,
>energy, and time. This forms a continuous space or domain which is divided
>into a set of bins that are not necessarily uniformly distributed or of
>equal size. Each bin is associated with the number of photons it contains.
>The number of photons may be expressed in various ways such as number,
>energy, and flux.
>
>This class may be thought of data obtain through the following process.
>Photons of various energies are detected as a function of time coming from
>points on the sky. Each photon is tagged by four numbers from a four
>dimensional continuous space. The numbers are a latitude and longitude on
>the celestial sphere from which the photon arrives, the energy of the
>photon, and the time. The continuous space is divided into a set of discrete
>regions or bins which are indexed in some fashion. The photons are counted
>in each bin. The details of the continuous energy, position, and time
>parameters are lost and only the bin index and bin counts are retained.
>
>This definition makes a notable distinction between the measured quantity,
>the photons, and the sampling, the bins. This distinction is often confused
>or lost. The photons, sometimes thought of as the "z" axis in an image, is
>the scientific content which is conveyed in standard physical units. The
>sampling or binning is variable and dependent on the way the data was
>obtained. The VO infrastructure or the data providers may "convert" units
>for the photon values and "resample" the bins at the request of the VO
>observer.
>
>To identify data which falls into this class we define a top level tag
>
>        VOCLASS = 4DBIN
>
>2.1 What is the difference between VO data and observational data?
>
>A key aspect of virtual observatory photon binned data is that the primary
>bin values be calibrated to standard physically meaningful units. There are
>two important reasons for this. One is to allow VO observers to easily
>intercompare data with only simple physical unit conversions. The other is
>to simplify the data model and limit metadata which must be supplied to
>allow meaningful interpretation.
>
>This does provide a small burden on the data providers above what has been
>typical. For instance, optical imaging often provides data in digital units
>with the conversion to photons implicit in a gain and a magnitude zeropoint.
>For VO data the data provider does the gain multiplication and conversion of
>the magnitude system to photon based units so that non-optical astronomers
>don't need to understand the detector technology, many of the ideas of
>magnitudes, and the metadata doesn't need to include a gain and magnitude
>zeropoint.
>
>In order to provide a "caveat emptor" option to the VO observers and data
>providers, a top-level metadata declaration is whether the primary data
>values meet the VO standard for this class:
>
>        4DBIN.CALIBRATED = [yes|no|relative]
>
>By asserting "no" the data may be useful but would require the VO observer
>to calibrate it themselves in some way. The "relative" calibration is a way
>to assert that the data is proportional to photon counts and that the
>response to photon fluxes is independent of position (after taking
>differences in bin sizes into account). Therefore, relative comparison
>between different bins is scientifically meaningful even though an absolute
>calibration is not defined.
>
>Note that the first sentence of this section refers to the "primary photon
>bin values". The reason for this is that the observational and calibration
>characteristics appear in the ancillary data and metadata. This is primarily
>contained in the uncertainties but some other useful information may be
>provided in exposure maps and data quality flags.
>
>2.2 What is an image and a spectrum?
>
>In as much as astronomers define and distinguish between "images" and
>"spectra", an image is a subclass with only a single energy bin, a single
>time bin, and multiple bins in both spatial parameters. The energy bin is
>often fairly wide but not always. A spectrum also has only a single time
>bin, but has more than one energy bin, and one or more spatial bins.
>
>Astronomers also typically discriminate between spectra having a single
>spatial bin, called a "one-dimensional spectrum", and multiple spatial bins,
>often called a "data cube". The special case of spatial bins restricted to a
>curve on the celestial sphere is called a "slit spectrum".
>
>In this document there is no distinction made between spectra and images.
>However, one could choose to subclass the metadata concepts. A subclass
>means using implicit and explicit conventions and defaults. The subclasses
>might be:
>
>        VOCLASS = 4DBIN.IMAGE
>        VOCLASS = 4DBIN.1DSPECTRUM
>        VOCLASS = 4DBIN.SLITSPECTRUM
>        VOCLASS = 4DBIN.DATACUBE
>
>3. Metadata
>
>Data from 4DBIN Class fundamentally consists of a set of numbers related to
>photon counts. To make sense of this set of numbers requires metadata or
>conventions which describe the relationship between photon counts and the
>bin value, define the bins, the uncertainties in the values, and associated
>attributes.
>
>As a thought experiment, which we use to identify the metadata through a use
>case, suppose one is given the set of numbers {0,6,7,2,5,3,1,4}. What do we
>need to understand something about the photons observed on the sky? Along
>these lines the minimal metadata necessary should be separated from optional
>metadata. Here we suggest the minimal description is provided by section 3.1
>on the bin geometry and section 3.2 on the bin values.
>
>First we need a top level piece of metadata defining the class and
>conventions. This type of metadata is sometimes associated with a name, such
>as FITS (with SIMPLE=T). For this document we define this metadata class
>domain
>
>        VOCLASS = 4DBIN
>
>3.1 Bin Geometry
>
>The metadata for the bin geometry describes the mapping from the continuous
>four dimensional photon parameter space to the discrete indexed bins. As
>noted in section 2, the bins are required to be described by a center and
>width along each of the four parameter dimensions. This constitutes the bin
>geometry.
>
>The first thing we need is a definition for the indexing of the data bin
>values. There are two straightforward ways to do this. One is to use the
>ordinal of the data value set. The other is to arrange the values into an
>array. For the 4DBIN class the array is required to be four dimensional.
>
>        4DBIN.INDEXING = ordinal
>        4DBIN.INDEXING = array(N1,N2,N3,N4)
>
>3.1.1 Ordinal or tabular indexing
>
>The first method is completely general while the second requires the number
>of data values to be the product of the array dimensions. At this point the
>two indexing schemes seem pretty much the same. The distinction comes in how
>the indices are used to map to the bin geometries in the four dimensional
>parameter space. In practice, the ordinal indexing is used with a table and
>the array is used for gridded bins.
>
>In the ordinal indexing the metadata includes a table of bin geometry
>values. The table is a set of numbers ordered such that each sequential set
>of eight values define a line and the line number corresponds to the data
>value with matching ordinal. For example, the first eight numbers apply to
>the first data value, the second eight to the second data value, and so
>forth. The eight values are the bin centers in longitude, latitude, energy,
>and time followed by bin widths.
>
>In the simple 1D spectrum example we might have
>
>  0 : 12h10m15s 32d15m10s 4001A 2003-05-07T12:10:15 1arcsec 1arcsec 1A 300s
>  6 : 12h10m15s 32d15m10s 4002A 2003-05-07T12:10:15 1arcsec 1arcsec 1A 300s
>
>3.1.2 Array or raster indexing
>
>For the array indexing we use a metadata description along the lines of the
>FITS WCS. This is a complex description which we only touch on here with
>attention to the restrictions imposed by the 4DBIN class. The metadata
>components would include many of the basic elements of the FITS WCS
>metadata. Besides the actual formalism for evaluating the bin centers and
>widths another key piece of metadata is the units of the four parameters.
>
>The main restriction on the FITS WCS formalism as it applies to the 4DBIN
>class is that the axes ordering is required to be latitude, longitude,
>energy, and time and so the FITS WCS is always a WCSDIM of 4. The FITS WCS
>does not currently explicitly define time coordinates. But for the main data
>types of interest, images and spectra with a single time bin, we simply use
>a linear WCS.
>
>The bin centers are a direct analog to the pixel centers in the FITS WCS.
>There is a linear mapping from the array index to an intermediate WCS
>coordinate. There is potentially a distortion transformation to an ideal
>intermediate coordinate. For calibrated data typical of the VO this should
>not be required except possibly to describe the path of a slit spectrum on
>the sky. Finally there is a projection or standard non-linear transformation
>to the final coordinates.
>
>One new feature of the FITS WCS formalism is use of a lookup table. This
>allows for bin centers which are not uniformly arrayed in the parameter
>space. It can provide similar information to the ordinal description.
>
>The concept of bin widths is only implicit in the FITS WCS formalism. For
>the array indexing metadata model defined here, the bin widths are computed
>from the WCS using the idea that the WCS functions are continuous in the
>index space. So the bin edges are computed by adding and subtracting
>one-half to the integer indices and evaluating the parameter value at those
>points. The WCS formalism is more general than simple rectangular bins so
>this computation is done by varying only the index of one parameter. The
>width of the bin is average difference from the integer index center and the
>two half index values.
>
>3.2 Bin Values
>
>Section 2.1 declares that calibrated 4DBIN data be in certain physical units
>directly related to the photons and the bin sizes. The primary metadata for
>the bin values is then the units. For example,
>
>    4DBIN.VALUES.UNITS = ergs/s/cm^2/A
>    4DBIN.VALUES.UNITS = photons
>    4DBIN.VALUES.UNITS = Jy
>
>The definition of the allowed units also needs to provide standards such as
>calibrations to above the atmosphere.
>
>When there is a significant variation in the detection of photons across an
>energy bin, such as occurs with a filter in a broadband image, the
>calibration must be referenced to the filter system.
>
>    4DBIN.FILTER = Johnson(B)
>
>Background contributions need to be described by primary metadata.
>
>    4DBIN.VALUES.BACKGROUND = Subtracted using nearby simultaneous observations
>    4DBIN.VALUES.BACKGROUND = Subtracted by CCD shuffling
>    4DBIN.VALUES.BACKGROUND = None subtracted
>
>3.4 Uncertainties
>
>For identification purposes, such as finding sources or redshifts, and when
>the magnitude of the signal is high, such as continuum shapes over decades
>of energy, the uncertainties about the data bin values may not be important.
>In other words, there a a number of uses for calibrated VO data that just
>depend on the data units and the the binning.
>
>But for detailed measurements where detection and instrumental effects are
>important, a significant piece of metadata are the uncertainties. There are
>two approaches which might be provided by the data model. The more rigorous
>approach would be to give statistical information about each bin (possibly
>including covariances).
>
>The statistical description of the uncertainties implicitly carries
>information about exposure times, rejected data in combined observations,
>variable sensitivities, and so on. Other attribute metadata may explicitly
>provide the means to separate these implicit contributions to the total
>uncertainties.
>
>The other is to provide a functional description. This is only really useful
>if the data is relatively homogeneous so that variable DQE, bin sizes, and
>backgrounds are not present. A typical model describes the variances as a
>function of the data values. For instance,
>
>        V = A + B N ...
>
>where N is the binned photon number.
>
>3.5 Attributes
>
>This section on attributes is a catch-all for all the rest of the metadata.
>This is all to be defined. However a quick list of common useful attributes
>is given below.
>
>     label/title
>          a label or title provided by the observer
>     object ID
>          a standard object id
>     instrument
>          details of the telescope and instrumentation
>     conditions
>          information about the observing conditions
>     calibrations
>          details of the calibrations
>
>     data quality
>          a table of data quality indicators for:
>             o uncalibrated bins due to vignetting or masking
>             o poorly calibrated bins
>     exposure map
>          a table of effective exposure times
>     exposure filter
>          a table describing chopping, shuffling, sequences of combined
>          exposures, etc. This is a filter function for the time
>          dimension of a bin.
>
>  
>

From - Mon May 12 22:10:04 2003
X-UIDL: 3e5baf650000095a
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4CK7ATA012982
	for <dal@ivoa.net>; Mon, 12 May 2003 22:07:10 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4CK79v21978
	for <dal@ivoa.net>; Mon, 12 May 2003 22:07:09 +0200 (MEST)
Received: from noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAACXaa7Q; Mon, 12 May 03 22:07:08 +0200
Received: from puppis.tuc.noao.edu ([140.252.4.30] verified)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 7326709; Mon, 12 May 2003 13:05:48 -0700
Received: (from valdes@localhost)
	by puppis.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) id NAA16261;
	Mon, 12 May 2003 13:05:48 -0700 (MST)
Date: Mon, 12 May 2003 13:05:48 -0700 (MST)
From: Frank Valdes <valdes@noao.edu>
Message-Id: <200305122005.NAA16261@puppis.tuc.noao.edu>
To: edward.j.shaya.1@gsfc.nasa.gov
Subject: Re: A Virtual Observatory Data Model
Cc: dal@ivoa.net
X-Sun-Charset: US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Ed,

I am going to agree with you in part, define some areas as calibration
issues, and throw out some ideas in response.

I like the idea of a WCS object.  The FITS WCS effort has led the way.
But their goals have been focused on the zeroth order aspect of WCS,
namely a point transformation from an index to a coordinate.  The WCS
data model needs to be expanded to higher order information.  The next
order would be to define pixel/bin extents.  One can do it, sort of,
with the scheme of saying the boundaries are half values of the index
but this is only an answer for certain types of sampling detectors that
have no gaps between the sample bins.

You identify another important aspect, resolution.  This is different
than coordinate uncertainties and bin sizes.   FITS WCS has tried to
define uncertainties somewhat.  Coordinate uncertainites tell you how
well you know where your sample bins are while resolution is, as you
say, how well you know photon information after the binning has lost
the precise identity of the photon.  I agree that this has to be a
higher order part of a data model for sampled photon count data.  This
is not, IMO, a calibration issue but an intrinsic property of the
sampling process.

There is more than one kind of crosstalk.  One is what you describe and
has the interpretation that you gave, that a photon which actually fell
in one bin "leaks" into another bin.  The other is one that I have to
deal with in mosaic data where a photon in one bin is counted but it
generates a small fraction of a spurious count in another bin which is
spatially disjoint (in another detector in fact).  Maybe the two could
be unified by some crosstalk coefficient but I'm not sure at the
moment.  Describing crosstalk seems to me to be a difficult thing to
do.  Note that I would argue that this is a instrumental problem that
should not be present (other than identified in an associated data
quality/uncertainty component) in calibrated VO data.  For our CCD
mosaic data we attempt to remove crosstalk effects in our calibrated
data.  I'm not sure how photon diffusion in a digital detector
could be calibrated and might have to be treated as a resolution effect.

While I was trying to develop the data model ideas that I presented I
was considering the idea that one should provide a "filter" function
for each bin.  There seems to be two filter functions, one based on
position in the 4D bin and the other in the 4D space.  In the first
category would be things like variable pixel sensitivity.  Maybe this
type of filter should be something that must be removed in VO
calibrated data?  In the second category is the usual filter concept
for a single wideband bin; ie. an image.  It might also include DQE in
energy and time windows in chopping or paused integrations. (Note I
think generally the DQE question goes away as part of the calibration
process.)  The resolution description could also be a part of this
second type of filter.

To try and summarize the minimum WCS-like functions to describe sampling bins
for a simple class of data:

bin center coordinates as a function of bin index
bin width or edge coordinates as a function of bin index
bin resolution, or filter function in 4D space, along each dimension
   as a function of bin index
    
So I agree with you, resolution is another important component of even a
simple data model.

Tracking a detector on a moving object is a very interesting thought.
Indeed, in the 4D binning model that means that over the course of the
collecting (the integration) the binning is changing.  If we wanted
this type of data to fall into the same VOCLASS as celestially tracked
data then it would require some time dependence in the bin geometry.
Describing this indirectly through the orbit of an object or by some
ephemeris would need to be decided.  In my view of data model classes I
might advocate that integrations along non-siderial tracks should be a
different class or subclass of data with specialized metadata.

Frank


> From edward.j.shaya.1@gsfc.nasa.gov Mon May 12 08:52:29 2003
> 
> Frank,
>     I think this is the right direction.  I just want to add a few items 
> that the scientist, even the non-instrument scientist, needs to have but 
> I think are missed here.
> 1. resolution - Although photons fall into bins or pixels, the 
> resolution tells one the probability that a photon in a particular bin 
> could have fallen into a nearby bin.
> 2. crosstalk - There is some tendency for the liberated electrons to 
> leak to the adjacent pixel.  So, even when pixel size is much larger the 
> spatial resolution the photon has a distinct probability of registering 
> in the wrong pixel.
> 
> I believe that time-series data is also covered by this model.
> VOCLASS = 4DBIN.TIMESERIES
> 
> Finally, what do we do about observations on a moving target (asteroid, 
> planet, comet, perhaps even high proper motion star)?   I think there 
> should be an option to substitute an object name for the two spatial 
> coordinates (unless you want to define a path on the celestial sphere).
> 
> Ed

From - Mon May 12 23:35:04 2003
X-UIDL: 3e5baf650000095b
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4CLVxBY019562
	for <dal@ivoa.net>; Mon, 12 May 2003 23:31:59 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4CLVw725409
	for <dal@ivoa.net>; Mon, 12 May 2003 23:31:58 +0200 (MEST)
Received: from noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA2saGNX; Mon, 12 May 03 23:31:58 +0200
Received: from puppis.tuc.noao.edu ([140.252.4.30] verified)
  by noao.edu (CommuniGate Pro SMTP 4.0.6)
  with ESMTP id 7327779; Mon, 12 May 2003 14:30:41 -0700
Received: (from valdes@localhost)
	by puppis.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) id OAA16272;
	Mon, 12 May 2003 14:30:41 -0700 (MST)
Date: Mon, 12 May 2003 14:30:41 -0700 (MST)
From: Frank Valdes <valdes@noao.edu>
Message-Id: <200305122130.OAA16272@puppis.tuc.noao.edu>
To: edward.j.shaya.1@gsfc.nasa.gov
Subject: Re: A Virtual Observatory Data Model
Cc: dal@ivoa.net
X-Sun-Charset: US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

My offhand comment about filters and resolution is somewhat confusing even
to me.  Thinking a little more precisely what you have is

  P(i|x,y,e,t) - prob. of detecting a photon in bin i given (x,y,e,t)

The mapping to index space is where the instrumental characteristics enter.
This function is not very practical.  Instead one would integrate over 
a bin j to get

  P(i|j) - prob. of detecting a photon in bin i given it should fall in bin j

If the indexing scheme for the bins is ordinal then this would take the form
of a sparse matrix.  It would only be diagonal for bins with one
parameter varying.

Even this is probaby too general for a simple data model.  A simpler
definition, which is close to how resolution is typically described in
image and spectral data, is to define "resolution" bins.  It would use
the same method used to describe the widths of the bins in the
continuous parameter space but define a probability (say 95%) that a
photon with parameter values corresponding to the center of the bin (or
with any value within the bin) is counted within the resolution bin.
The exact definition TBD.  These resolution bins may or may not
overlap.

Some more food for thought,
Frank

From - Tue May 13 17:10:05 2003
X-UIDL: 3e5baf6500000971
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4DF6gBY027436
	for <dal@ivoa.net>; Tue, 13 May 2003 17:06:42 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4DF6gM24769
	for <dal@ivoa.net>; Tue, 13 May 2003 17:06:42 +0200 (MEST)
Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAKwaOxW; Tue, 13 May 03 17:06:41 +0200
Received: from stsci.edu (winds.stsci.edu [130.167.236.235])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AEF47730;
	Tue, 13 May 2003 11:06:36 -0400 (EDT)
Message-ID: <3EC109FC.FE21F802@stsci.edu>
Date: Tue, 13 May 2003 11:06:36 -0400
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Re: spectral data
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

In response to Anita Richards:

> Regarding Ivo Busko's document on Generic Spectral Data Structures, I 
> guess this is just for handling certain types of data? as it does not seem 
> to cover the 3 or 4 D cases, e.g. datacubes, described by Frank Valdes. 
> This is not a criticism, as I am sure Specview is very good in its domain, 
> but it will not meet all the near future needs of the VO. 

Absolutely. The "generic" spectral data structures we conceived for the
Specview software address just the particular requirements of the software, 
and they cannot come even close to what a VO standard needs. As you pointed 
out, the extra dimensiosn (spatial and temporal) were left out entirely. This
is because they were not part of the requirements. 

The point of contact between Specview's data structures and a (much) more 
comprehensive VO standard would be, in my view, in the area of minimum
support. That is, what should minimally a VO standard support in terms of
spectral data ? The answer to this question would almost necessarily include
some, or most, of the elements we included in Specview's data structures, such
as physical units, extra data arrays besides the flux and wavelength ones,
data quality, etc. Such elements would in a sense be folded into the more generic
multi-dimensional structures.

-Ivo

From - Tue May 13 21:55:06 2003
X-UIDL: 3e5baf650000097e
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4DJsoBY007261
	for <dal@ivoa.net>; Tue, 13 May 2003 21:54:50 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4DJsoC25963
	for <dal@ivoa.net>; Tue, 13 May 2003 21:54:50 +0200 (MEST)
Received: from mail630.gsfc.nasa.gov(128.183.190.39) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAM_aaTY; Tue, 13 May 03 21:54:49 +0200
Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136])
	by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h4DJrgAV012449;
	Tue, 13 May 2003 15:53:44 -0400
Message-ID: <3EC14D40.5070007@gsfc.nasa.gov>
Date: Tue, 13 May 2003 15:53:36 -0400
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
Reply-To: edward.j.shaya.1@gsfc.nasa.gov
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Frank Valdes <valdes@noao.edu>
CC: dal@ivoa.net
Subject: Re: A Virtual Observatory Data Model
References: <200305122130.OAA16272@puppis.tuc.noao.edu>
In-Reply-To: <200305122130.OAA16272@puppis.tuc.noao.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

Frank,
   
    I see now that resolution is not cleanly described as a probability 
function on the pixels,
since it is a rough description of the PSF which was convolved with the 
perfect image to create the observed image.  There are varying degrees 
of descriptions for the PSF:
1) A FWHM for each axis.  Mention of whether to use a Gaussian or an 
Airy disk would be nice.
2) Same as 1 but different values for different parts of the 4DBin Object.
3) A 4D PSF. this would probably be a URL to a 4DBin Object
4) Same as 3 but a different PSF for different parts of the 4DBin Object.

The cross-talk that I mention could be handled somewhat like the 
resolution.  It is different however, because in this case it is a 
function of the location on the pixel.  A cusp centered on a pixel will 
blur less than a cusp centered near the edge of the pixel.  PSF 
convolution does not work that way.

Ed
PS - I have to run off to the Cambridge meeting right now.  Still to 
come, how to put the
list of describing elements of the 4DBin object into XML.




Frank Valdes wrote:

>My offhand comment about filters and resolution is somewhat confusing even
>to me.  Thinking a little more precisely what you have is
>
>  P(i|x,y,e,t) - prob. of detecting a photon in bin i given (x,y,e,t)
>
>The mapping to index space is where the instrumental characteristics enter.
>This function is not very practical.  Instead one would integrate over 
>a bin j to get
>
>  P(i|j) - prob. of detecting a photon in bin i given it should fall in bin j
>
>If the indexing scheme for the bins is ordinal then this would take the form
>of a sparse matrix.  It would only be diagonal for bins with one
>parameter varying.
>
>Even this is probaby too general for a simple data model.  A simpler
>definition, which is close to how resolution is typically described in
>image and spectral data, is to define "resolution" bins.  It would use
>the same method used to describe the widths of the bins in the
>continuous parameter space but define a probability (say 95%) that a
>photon with parameter values corresponding to the center of the bin (or
>with any value within the bin) is counted within the resolution bin.
>The exact definition TBD.  These resolution bins may or may not
>overlap.
>
>Some more food for thought,
>Frank
>
>  
>

From - Fri May 16 15:35:11 2003
X-UIDL: 3e5baf65000009dd
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4GDYHCS010110
	for <dal@ivoa.net>; Fri, 16 May 2003 15:34:17 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4GDYHU05009
	for <dal@ivoa.net>; Fri, 16 May 2003 15:34:17 +0200 (MEST)
Received: from cv3.cv.nrao.edu(192.33.115.2) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA4YaaYj; Fri, 16 May 03 15:34:16 +0200
Received: from polaris.cv.nrao.edu (polaris.cv.nrao.edu [192.33.115.101])
	by cv3.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h4GDV4m05793
	for <dal@ivoa.net>; Fri, 16 May 2003 09:31:04 -0400
Received: from oak (oak.aoc.nrao.edu [146.88.1.137])
	by polaris.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h4GDV4Z08158
	for <dal@ivoa.net>; Fri, 16 May 2003 09:31:04 -0400
Date: Fri, 16 May 2003 07:30:59 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net
Subject: IVOA DAL working group summary
Message-ID: <Pine.LNX.4.44.0305160655120.28569-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.2, required 7,
	SPAM_PHRASE_00_01, USER_AGENT_PINE)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

The Cambridge IVOA interoperability workshop has now concluded.  I think we
made good progress on all fronts.

A summary of the recommendations of the Cambridge meeting of the DAL working
group (as presented on Friday in the plenary session) can be found at

    http://www.ivoa.net/internal/IVOA/InterOpMay2003DAL/IVOA-DAL-Summary.pdf

This document and various other materials from the DAL WG discussions can be
found at

    http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003DAL

Please feel free to comment on any of this material, in particular the
proposed service architecture and the roadmap and priorities for year 1.

	- Doug

From - Mon May 19 00:45:16 2003
X-UIDL: 3e5baf65000009f6
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h4IMj7cA014095
	for <dal@ivoa.net>; Mon, 19 May 2003 00:45:08 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h4IMj7O24490
	for <dal@ivoa.net>; Mon, 19 May 2003 00:45:07 +0200 (MEST)
Received: from lsstmail.org(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAEmaG0V; Mon, 19 May 03 00:45:06 +0200
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.1b6)
  with ESMTP id 7387575 for dal@ivoa.net; Sun, 18 May 2003 15:43:49 -0700
Date: Sun, 18 May 2003 16:43:50 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: dal@ivoa.net
Subject: Re: IVOA DAL working group summary
In-Reply-To: <Pine.LNX.4.44.0305160655120.28569-100000@oak>
Message-ID: <Pine.LNX.4.44.0305181637290.27149-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Status:   

I made some minor edits to the summary recommendations (link below)
based on the discussions we had in the final  plenary session last Friday.  
Specifically, "SkyImage" in the Primary DAL Services figure was changed
to "NDImage" to make it clear that the general image service will handle
cases such as spectral data cubes as well as 2D sky images.  This also
gives us "catalog" and "image" as the base classes and makes the whole
hierarchy more straightforward.   Doug


On Fri, 16 May 2003, Doug Tody wrote:

> The Cambridge IVOA interoperability workshop has now concluded.  I think we
> made good progress on all fronts.
> 
> A summary of the recommendations of the Cambridge meeting of the DAL working
> group (as presented on Friday in the plenary session) can be found at
> 
>     http://www.ivoa.net/internal/IVOA/InterOpMay2003DAL/IVOA-DAL-Summary.pdf
> 
> This document and various other materials from the DAL WG discussions can be
> found at
> 
>     http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2003DAL
> 
> Please feel free to comment on any of this material, in particular the
> proposed service architecture and the roadmap and priorities for year 1.
> 
> 	- Doug
> 
> 

From - Thu Jun 19 05:15:56 2003
X-UIDL: 3e5baf650000110a
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5J3FuAo028694
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 05:15:56 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5J3Fu1P028693
	for dal-outgoing; Thu, 19 Jun 2003 05:15:56 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5J3FnAo028673
	for <dal@ivoa.net>; Thu, 19 Jun 2003 05:15:49 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5J3Fmc12705
	for <dal@ivoa.net>; Thu, 19 Jun 2003 05:15:48 +0200 (MEST)
Received: from email.tuc.noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAiOaa0y; Thu, 19 Jun 03 05:15:47 +0200
X-SpamCatcher-Score:   1 [X]
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.1b8)
  with ESMTP id 7764623 for dal@ivoa.net; Wed, 18 Jun 2003 20:14:30 -0700
Date: Wed, 18 Jun 2003 21:14:28 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: IVOA Data Access Layer <dal@ivoa.net>
Subject: Simple Spectral Access use cases
Message-ID: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
Status:   

At the IVOA meeting in Cambridge a few weeks ago, one of the highest
priority projects identified for the DAL working group was to define a
"simple spectral access" protocol for accessing 1D spectra and SEDs.

To help plan this effort it would help to get a better idea of how such an
interface would initially be used.  If you think you or your institution
might provide 1D spectral data or SEDs to the VO, or might provide software
to use such data provided by the VO (e.g., as an addition to an existing
VO demo or by interfacing some analysis application), please fill in the
following form and return it to dal@ivoa.net.  Note doing so is not a
committment to actually do any work!  We mainly just want to get a better
idea of what spectral data collections are out there, to help design the
spectral data interface.  Thanks very much for your help with this.

Doug Tody (dtody@nrao.edu), Markus Dolensky (Markus.Dolensky@eso.org)


Simple Spectral Access Use Cases

Data Providers (e.g., data centers, archives)

    - Data provider name

    - Spectral data collections from this source

    - Characteristics of data (number of spectra, size, irregularly sampled,
      nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.)

    - Current data storage format

    - Is the data available online?

    - Other comments


Data Consumers (e.g., analysis packages, e.g., VO demonstrations that might
want to add the ability to fetch and display a spectrum)

    - Name of application, package, demo, etc.

    - Summarize capabilities of software

    - Desired characteristics of input data

    - Desired input data format or formats (e.g., graphics, FITS, XML)

    - Other comments


General Comments 


From - Thu Jun 19 17:30:56 2003
X-UIDL: 3e5baf650000111a
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JFR5M0012198
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 17:27:05 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5JFR5gs012197
	for dal-outgoing; Thu, 19 Jun 2003 17:27:05 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JFQxM0012187
	for <dal@ivoa.net>; Thu, 19 Jun 2003 17:27:00 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5JFQw708546
	for <dal@ivoa.net>; Thu, 19 Jun 2003 17:26:58 +0200 (MEST)
Received: from donner.stsci.edu(130.167.251.65) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAWcaiSq; Thu, 19 Jun 03 17:26:57 +0200
Received: from stsci.edu (winds.stsci.edu [130.167.236.235])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.3-GR)
	with ESMTP id AEP43163;
	Thu, 19 Jun 2003 11:25:40 -0400 (EDT)
Message-ID: <3EF1D5F3.4D63E66B@stsci.edu>
Date: Thu, 19 Jun 2003 11:25:39 -0400
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Re: Simple Spectral Access use cases
References: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ivo Busko <busko@stsci.edu>
Status:   

Doug Tody wrote:
<snip>
> Data Consumers (e.g., analysis packages, e.g., VO demonstrations that might
> want to add the ability to fetch and display a spectrum)
> 
>     - Name of application, package, demo, etc.
 
        Specview

>     - Summarize capabilities of software

        Spectral display and analysis software. For a list of
capabilities,
        see here: 
       
http://www.stsci.edu/resources/software_hardware/specview/what_is_specview
        and for a list of future capabilities, see here:
       
http://www.stsci.edu/resources/software_hardware/specview/upcoming 

>     - Desired characteristics of input data

        As a minimum, data should consist of (x,y) pairs of
wavelength-flux
        values expressed in wavelength/frequency/energy units, and
spectral
        flux density units respectively. The units information should be
present
        as well, in header keywords or table column descriptors or any
other
        suitable form.

        Additional information that could be included with the above,
(if
        available) is a third value associated with each (x,y) pair 
        representing the measurement error in flux density. Also, it
won't
        hurt if obvious pieces of information such as the object name,
are
        provided as well.

        Uncalibrated data (such as in counts/s units) can also be
ingested
        but not much else can be done with it besides plain ploting.

        A description of the currently supported data formats can be
seen
        here:
       
http://www.stsci.edu/resources/software_hardware/specview/formats
        Formats that share some resemblance with these can be included
in 
        the repertoire of supported formats with minimal effort.

>     - Desired input data format or formats (e.g., graphics, FITS, XML)

        FITS (images, tables), XML, and plain ASCII are all supported at
this
        point. It is fairly easy to write ingestor modules for almost
        any conceivable spectral format that uses one of those media.


-Ivo

 *********************************************************************
 *  Ivo C. Busko, PhD                        e-mail: busko@stsci.edu *
 *  Senior Systems Software Engineer                                 *
 *  Science Software Branch                                          *
 *  Engeneering and Software Services Division  Voice: (410)338-4472 *
 *  Space Telescope Science Institute             FAX: (410)338-4767 *
 *  3700 San Martin Drive                                            *
 *  Baltimore MD 21218-2410  USA                                     *
 *********************************************************************

From - Thu Jun 19 17:55:57 2003
X-UIDL: 3e5baf650000111b
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JFpYM0016194
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 17:51:34 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5JFpY7a016193
	for dal-outgoing; Thu, 19 Jun 2003 17:51:34 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JFpVM0016185
	for <dal@ivoa.net>; Thu, 19 Jun 2003 17:51:31 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5JFpVs09645
	for <dal@ivoa.net>; Thu, 19 Jun 2003 17:51:31 +0200 (MEST)
Received: from fsui02.fnal.gov(131.225.68.20) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAALGaG1s; Thu, 19 Jun 03 17:51:30 +0200
Received: from localhost (skent@localhost)
	by fsui02.fnal.gov (8.11.6p2/8.11.6) with ESMTP id h5JFpQL22261;
	Thu, 19 Jun 2003 10:51:27 -0500 (CDT)
X-Authentication-Warning: fsui02.fnal.gov: skent owned process doing -bs
Date: Thu, 19 Jun 2003 10:51:26 -0500 (CDT)
From: Stephen Kent <skent@fnal.gov>
To: <dal@ivoa.net>
cc: <dtody@nrao.edu>
Subject: Use case for spectral data
Message-ID: <Pine.GSO.4.31.0306191048230.20496-100000@fsui02.fnal.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Stephen Kent <skent@fnal.gov>
Status:   

As per request, here is information for the SDSS spectral data.

Steve Kent

Simple Spectral Access Use Cases

Data Providers (e.g., data centers, archives)

    - Data provider name
	Fermilab

    - Spectral data collections from this source
	Sloan Digital Sky Survey, Data Release 1

    - Characteristics of data (number of spectra, size, irregularly sampled,
      nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.)
	Number: 186,000
	Size:  ~160 Kbytes per spectrum, ~3850 pixels in wavelength direction
	Sampling: Uniform in log wavelength, resolution 1800
	Arrays: Spectrum, continuum-subtracted, noise, mask
	Wavelength range: 3800-9200
	Tables:  Emission, absorption lines and parameters, emission redshift
	   parameters, cross-correlation parameters.

    - Current data storage format
	FITS files

    - Is the data available online?
	Yes: through www.sdss.org

    - Other comments
	Cover ~1300 square degrees of sky.

From - Thu Jun 19 18:00:57 2003
X-UIDL: 3e5baf650000111d
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JFvPM0017004
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 17:57:25 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5JFvPAL017003
	for dal-outgoing; Thu, 19 Jun 2003 17:57:25 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JFvKM0016990
	for <dal@ivoa.net>; Thu, 19 Jun 2003 17:57:21 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5JFvKQ09901
	for <dal@ivoa.net>; Thu, 19 Jun 2003 17:57:20 +0200 (MEST)
Received: from hail.ipac.caltech.edu(134.4.10.131) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAARVa4ut; Thu, 19 Jun 03 17:57:19 +0200
Received: from hail.ipac.caltech.edu ([127.0.0.1])
	by hail.ipac.caltech.edu (8.11.7/8.11.6) with ESMTP id h5JFvGu18237
	for <dal@ivoa.net>; Thu, 19 Jun 2003 08:57:17 -0700 (PDT)
Received: from ipac.caltech.edu (localhost [127.0.0.1])
	by hail.ipac.caltech.edu (8.11.7/8.11.6) with SMTP id h5JFvGE18232
	for <dal@ivoa.net>; Thu, 19 Jun 2003 08:57:16 -0700 (PDT)
From: Bruce Berriman <gbb@ipac.caltech.edu>
Received: from 24.205.141.70
        (SquirrelMail authenticated user gbb)
        by webmail.ipac.caltech.edu with HTTP;
        Thu, 19 Jun 2003 08:57:16 -0700 (PDT)
Message-ID: <9702.24.205.141.70.1056038236.squirrel@webmail.ipac.caltech.edu>
Date: Thu, 19 Jun 2003 08:57:16 -0700 (PDT)
Subject: [Fwd: Re: Simple Spectral Access use cases]
To: <dal@ivoa.net>
X-Mailer: SquirrelMail (version 1.2.0 [rc2])
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Bruce Berriman <gbb@ipac.caltech.edu>
Status:   


Colleagues:

Also some long wave spectra are delivered as Antenna temperature vs,
frequency.The SWAS spectra are for instance in this format.

Bruce Berriman


-------- Original Message --------
Subject: Re: Simple Spectral Access use cases
From: Ivo Busko <busko@stsci.edu>
To: dal@ivoa.net

Doug Tody wrote:
<snip>
> Data Consumers (e.g., analysis packages, e.g., VO demonstrations that
> might want to add the ability to fetch and display a spectrum)
>
>     - Name of application, package, demo, etc.

        Specview

>     - Summarize capabilities of software

        Spectral display and analysis software. For a list of
capabilities,
        see here:

http://www.stsci.edu/resources/software_hardware/specview/what_is_specview
        and for a list of future capabilities, see here:

http://www.stsci.edu/resources/software_hardware/specview/upcoming

>     - Desired characteristics of input data

        As a minimum, data should consist of (x,y) pairs of
wavelength-flux
        values expressed in wavelength/frequency/energy units, and
spectral
        flux density units respectively. The units information should be
present
        as well, in header keywords or table column descriptors or any
other
        suitable form.

        Additional information that could be included with the above,
(if
        available) is a third value associated with each (x,y) pair
        representing the measurement error in flux density. Also, it
won't
        hurt if obvious pieces of information such as the object name,
are
        provided as well.

        Uncalibrated data (such as in counts/s units) can also be
ingested
        but not much else can be done with it besides plain ploting.

        A description of the currently supported data formats can be
seen
        here:

http://www.stsci.edu/resources/software_hardware/specview/formats
        Formats that share some resemblance with these can be included
in
        the repertoire of supported formats with minimal effort.

>     - Desired input data format or formats (e.g., graphics, FITS, XML)

        FITS (images, tables), XML, and plain ASCII are all supported at
this
        point. It is fairly easy to write ingestor modules for almost any
        conceivable spectral format that uses one of those media.


-Ivo

 ********************************************************************* *
 Ivo C. Busko, PhD                        e-mail: busko@stsci.edu * *
 Senior Systems Software Engineer                                 * *
 Science Software Branch                                          * *
 Engeneering and Software Services Division  Voice: (410)338-4472 * *
 Space Telescope Science Institute             FAX: (410)338-4767 * *
 3700 San Martin Drive                                            * *
 Baltimore MD 21218-2410  USA                                     *
 *********************************************************************



From - Thu Jun 19 18:20:56 2003
X-UIDL: 3e5baf650000111e
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JGJSM0020372
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 18:19:28 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5JGJSFU020371
	for dal-outgoing; Thu, 19 Jun 2003 18:19:28 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JGJLM0020356
	for <dal@ivoa.net>; Thu, 19 Jun 2003 18:19:22 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5JGJLo11068
	for <dal@ivoa.net>; Thu, 19 Jun 2003 18:19:21 +0200 (MEST)
Received: from poplar.ncsa.uiuc.edu(141.142.65.122) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAAuayNv; Thu, 19 Jun 03 18:19:20 +0200
Received: from localhost (rplante@localhost)
	by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id h5JGJJ114481
	for <dal@ivoa.net>; Thu, 19 Jun 2003 11:19:19 -0500
Date: Thu, 19 Jun 2003 11:19:19 -0500 (CDT)
From: Ray Plante <rplante@poplar.ncsa.uiuc.edu>
To: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: Simple Spectral Access use cases
In-Reply-To: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
Message-ID: <Pine.LNX.4.44.0306191114000.12073-100000@poplar.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ray Plante <rplante@poplar.ncsa.uiuc.edu>
Status:   

On Wed, 18 Jun 2003, Doug Tody wrote:
> Data Providers (e.g., data centers, archives)
> 
>     - Data provider name

NCSA

>     - Spectral data collections from this source

NCSA Astronomy Digital Image Library
(NCSA BIMA Data Archive)

>     - Characteristics of data (number of spectra, size, irregularly sampled,
>       nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.)

Library contains a large number of radio spectral image cubes

>     - Current data storage format

FITS

>     - Is the data available online?

Yes

>     - Other comments

An interesting service would be to generate 1-D spectra from cubes on the 
fly.  In addition to the usual search paramters, users would have to 
provide a spatial resolution.  This service would be analogous to an
image cutout service in that the output is generated to user specs
on-the-fly from the underlying data.  

cheers,
Ray




From - Thu Jun 19 18:50:57 2003
X-UIDL: 3e5baf6500001120
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JGlbM0024965
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 18:47:37 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5JGlbTx024961
	for dal-outgoing; Thu, 19 Jun 2003 18:47:37 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JGlWM0024936
	for <dal@ivoa.net>; Thu, 19 Jun 2003 18:47:32 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5JGlWl12570
	for <dal@ivoa.net>; Thu, 19 Jun 2003 18:47:32 +0200 (MEST)
Received: from lheapop.gsfc.nasa.gov(128.183.16.62) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAAea4Iy; Thu, 19 Jun 03 18:47:31 +0200
Received: from nasa.gov (silk2.gsfc.nasa.gov [128.183.19.104])
	by milkyway.gsfc.nasa.gov (8.12.8/8.12.8) with ESMTP id h5JGlOe4024627;
	Thu, 19 Jun 2003 12:47:24 -0400
Message-ID: <3EF1E91B.7010504@nasa.gov>
Date: Thu, 19 Jun 2003 12:47:23 -0400
From: Tom McGlynn <Thomas.A.McGlynn@nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Doug Tody <dtody@nrao.edu>
CC: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: Simple Spectral Access use cases
References: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Tom McGlynn <Thomas.A.McGlynn@nasa.gov>
Status:   

> Simple Spectral Access Use Cases
> 
> Data Providers (e.g., data centers, archives)
> 
>     - Data provider name
            HEASARC

> 
>     - Spectral data collections from this source
            Variety of spectral data sources from X-ray and gamma-ray
            missions, including both relatively high and low resolution
	   spectral data.

> 
>     - Characteristics of data (number of spectra, size, irregularly sampled,
>       nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.)
            Typically thousands of sources per mission.
            Many distinct spectral types, e.g.,
                Event lists (Einstein, ROSAT, ASCA, XMM) (individual photon events
                with energy information.  These can be the basis of spatial/spectral
	       data sets.)
                PHA files (Einstein, ROSAT, EXOSAT, XMM?) (these are most
                similar to conventional 1-d spectra)
                Time resolved spectral information (XTE, BATSE, Swift, HETE) (There
                are very complex formats here to deal with bright brief transients
                while XTE has a variety of modes to select between temporal and
                spectral resolution).
            Complex formats for calibration information
            Coded aperture mask data (INTEGRAL)

> 
>     - Current data storage format

                All data are stored in FITS formats

> 
>     - Is the data available online?

                Yes

> 
>     - Other comments

		Even at this leve of detail it may be inappropriate
		to discuss the HEASARC monolithically.  The characteristics
  		of individual missions/instruments varies enormously.




From - Thu Jun 19 21:00:57 2003
X-UIDL: 3e5baf6500001124
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JIvYM0021327
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 20:57:34 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5JIvYd0021326
	for dal-outgoing; Thu, 19 Jun 2003 20:57:34 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JIvSM0021285
	for <dal@ivoa.net>; Thu, 19 Jun 2003 20:57:28 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5JIvRg18155
	for <dal@ivoa.net>; Thu, 19 Jun 2003 20:57:27 +0200 (MEST)
Received: from lsstmail.org(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAWwa4CJ; Thu, 19 Jun 03 20:57:26 +0200
Received: from puppis.tuc.noao.edu ([140.252.4.30] verified)
  by noao.edu (CommuniGate Pro SMTP 4.1b8)
  with ESMTP id 7773853 for dal@ivoa.net; Thu, 19 Jun 2003 11:57:25 -0700
Received: (from valdes@localhost)
	by puppis.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) id LAA02980
	for dal@ivoa.net; Thu, 19 Jun 2003 11:57:25 -0700 (MST)
Date: Thu, 19 Jun 2003 11:57:25 -0700 (MST)
From: Frank Valdes <valdes@noao.edu>
Message-Id: <200306191857.LAA02980@puppis.tuc.noao.edu>
To: dal@ivoa.net
Subject: Re: Simple Spectral Access use cases
X-Sun-Charset: US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Frank Valdes <valdes@noao.edu>
Status:   

Simple Spectral Access Use Cases

Data Providers (e.g., data centers, archives)

    - Data provider name:
	NOAO and CFLIB project

    - Spectral data collections from this source
	Indo-U.S. Library of Coude Feed Stellar Spectra

    - Characteristics of data (number of spectra, size, irregularly sampled,
      nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.)
	There are/will be a variety of data products.  As a summary:
	1. Linearized, spliced, normalized flux:
	    1300 spectra, 15000 pixels, 3465-9469A @ 0.44A/pix
	2. Individual exposures in 1D array with non-linear sampling:
	    1300 stars, ~5 pieces/star, 3065 pixels @ 0.44A/pix
	3. Same as (2) but in observed counts.
	4. Variance arrays for all in this or next version
	5. Headers and database provide Simbad and physical parameters.
	    The library was designed to sample a wide variety of stellar
	    parameters: Teff, log(g), [Fe/H].

    - Current data storage format
	FITS simple image, FITS MEF
	Simple linear WCS, IRAF non-linear multispec WCS

    - Is the data available online?
	First ftp release in the next couple of months.

    - Other comments
	The paper is being written.  The first release will likely be
	by FTP.  In the longer term this will be a good library for
	archive and web service access.  Will eventually become part of
	the NOAO Science Archive.

	Team: F. Valdes, J. Rose, D. Bell, R. Gupta, H. Singh


Data Consumers (e.g., analysis packages, e.g., VO demonstrations that might
want to add the ability to fetch and display a spectrum)

    - Name of application, package, demo, etc.
	 NOAO/IRAF

    - Summarize capabilities of software
	 Full featured for viewing and analysis.  Includes SPECTOOL, a
	 powerful windows-GUI browsing application.

    - Desired characteristics of input data
	 FITS or ascii, FITS WCS, most useful for well sampled rasters.

    - Desired input data format or formats (e.g., graphics, FITS, XML)
	 FITS 1D, 2D, 3D rasters with WCS
	 FITS binary tables
	 Ascii "tables"

    - Other comments
	 1D and 2D currently have more applications than 3D
	 FITS binary tables format and support under development
	 Will be evolved to support VO spectral standards

	 Team: F. Valdes and NOAO DPP


General Comments 


Frank Valdes

From - Thu Jun 19 22:30:57 2003
X-UIDL: 3e5baf6500001125
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JKV0M0018836
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 19 Jun 2003 22:31:00 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5JKV0GH018835
	for dal-outgoing; Thu, 19 Jun 2003 22:31:00 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5JKUuM0018826
	for <dal@ivoa.net>; Thu, 19 Jun 2003 22:30:56 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5JKUtP22944
	for <dal@ivoa.net>; Thu, 19 Jun 2003 22:30:55 +0200 (MEST)
Received: from wiyn.org(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAdza4ZS; Thu, 19 Jun 03 22:30:54 +0200
Received: from tucana.tuc.noao.edu ([140.252.1.1] verified)
  by noao.edu (CommuniGate Pro SMTP 4.1b8)
  with ESMTP id 7774858; Thu, 19 Jun 2003 13:30:53 -0700
Received: (from fitz@localhost)
	by tucana.tuc.noao.edu (8.11.3/8.11.3/SAG-04Apr12) id h5JKUq808003;
	Thu, 19 Jun 2003 13:30:52 -0700 (MST)
Date: Thu, 19 Jun 2003 13:30:52 -0700 (MST)
From: Mike Fitzpatrick <fitz@noao.edu>
Message-Id: <200306192030.h5JKUq808003@tucana.tuc.noao.edu>
To: dal@ivoa.net, dtody@nrao.edu
Subject: Re:  Simple Spectral Access use cases
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Mike Fitzpatrick <fitz@noao.edu>
Status:   


	Forgive me for not just lumping these all as "various NOAO spectral
libraries" but I though the different storage formats and associated data
tables would provide for some interesting use cases.  Something like a
cutout service might be appropriate for some of the data, the challenging
thing for us however to put all these into an SSA is simply the variety
of local data access methods required.


Cheers,
-Mike


Data Providers (e.g., data centers, archives)

Provider Name:	  NOAO
Collection:	  High Resolution Atlas of Arcturus Spectra - 0.92-5.36 microns
Characteristics:  310 ASCII tables of wavenumber vs flux
Storage Format:   Text tables
Available online: ftp://ftp.noao.edu/catalogs/arcturusatlas/ir
Comments:	  Tables contain three flux values (arcturus spectrum,
		  telluric spectrum and ratio) for both summer and winter
		  observations.  Additional data for atomic and molecular
		  line identifications.  Atlas by Hinkle, Wallace, Livingston,
		  Valenti, and Harmer.

-----------------------------------------------------------------------------

Provider Name:	  NOAO
Collection:	  High Resolution Atlas of Arcturus Spectra - 3727-9300 A
Characteristics:  57 ASCII tables of wavelength vs flux, also available as
		  FITS multispec or binary table images. Linear WCS
Storage Format:   Text tables, FITS images, or FITS Binary Tables
Available online: ftp://ftp.noao.edu/catalogs/arcturusatlas/visual
Comments:	  Tables contain three flux values (arcturus spectrum,
		  solar flux and telluric transmission used to correct solar
	  	  flux spectrum).  Additional data for atomic and molecular
		  line identifications.  Atlas by Hinkle, Wallace, Valenti,
		  and Harmer.

-----------------------------------------------------------------------------

Provider Name:	  NOAO
Collection:	  Library of High Resolution Infrared Stellar Spectra in K-Band
Characteristics:  Digital spectra for 17 cool stars in the 2.02-2.42 micron
		  region.  The spectra have been corrected for telluric
		  absorption and are at a resolution >45000. Linear WCS
Storage Format:   Text files
Available online: ftp://ftp.noao.edu/catalogs/hiresK/README
Comments:	  Tables contain one or two spectra and optionally an atmos-
		  speric transmission function.  Wallace and Hinkle 1996 ApJS
		  107 312.

-----------------------------------------------------------------------------

Provider Name:	  NOAO
Collection:	  Library of Medium Resolution Infrared Stellar Spectra
Characteristics:  Spectra of 147 MK standard stars covering the H, J, and K
		  bands. The spectra have been corrected for telluric absorp-
		  tion and are at a resolution of 3000. Linear WCS
Storage Format:   FITS images
Available online: ftp://ftp.noao.edu/catalogs/medresIR
Comments:	  Spectra are from five papers by (variously) Wallace, Hinkle,
		  Meyer, Edwards, and Strom.

-----------------------------------------------------------------------------

Provider Name:	  NOAO
Collection:	  Coude Feed Spectral Library
Characteristics:  Spectra of 684 stars observed with the Coudi Feed telescope
		  and spectrograph at KPNO. The spectra cover the ranges
      		  3820 - 4500 E and 4780 - 5460 E at a resolution of 1.8 A
		  FWHM (~60 km/sec).  Linear WCS
Storage Format:   FITS images
Available online: ftp://ftp.noao.edu/catalogs/coudelib
Comments:	  Library of stellar spectra covering a wide variety of
		  spectral types, luminosity classes, and metallicities.
		  Sample selection was based almost entirely on the availabil-
		  ity of atmospheric parameters for the stars.  Leitherer, C.
		  et al. 1996 PASP, 108, 996. 

-----------------------------------------------------------------------------

Provider Name:	  NOAO
Collection:	  Library of Stellar Spectra
Characteristics:  160 1-D spectra covering 3510-7430 A at a resolution of
		  1.4 A/pix, linear WCS
Storage Format:   FITS images
Available online: ftp://ftp.noao.edu/catalogs/jacobyetal.spec/
Comments:	  Library of stellar spectra covering entire range of spectral
		  types.  G.H. Jacoby, D.A Hunter, and C.A. Christian, "A
		  Library of Stellar Spectra", in ApJ Supp. 56, 257.

-----------------------------------------------------------------------------

Provider Name:		  NOAO
Collection:	  Optical Spectrophotometric Atlas of SN 1987A
Characteristics:  139 flux-calibrated 1-D spectra at various wavelength
		  coverages and resolution, linear WCS
Storage Format:   FITS images
Available online: ftp://ftp.noao.edu/sn1987a
Comments:	  Observations from Day 198 to 805, archive consists of CCD
		  spectra of SN 1987A obtained with the CTIO 1.5m and 4m
		  telescopes.   Additionally, table of observing conditions
		  for each image and UBVRI photometry

-----------------------------------------------------------------------------

Provide Name:	  NOAO
Collection:	  Atlases of ThAR, FeAr, and HeNeAr comparison spectra
Characteristics:  ThAr:   covers 3005-10598A @ 0.02 A/pix, ~380000 pixels
		  FeAr:   covers 3000-10900A @ 0.2 A/pix, ~38000 pixels
		  HeNeAr: covers 3300-11100A @ 0.35 A/pix, ~24000 pixels
Storage Format:   FITS images
Available online: http://www.noao.edu/kpno/specatlas/thar/thar.html
		  http://www.noao.edu/kpno/specatlas/fear/fear.html
		  http://www.noao.edu/kpno/specatlas/henear/henear.html
Comments:	  Atlases are currently used in a web service providing 
	 	  cutout FITS images in a given wavelength range, linelists,
		  and labeled line identification plots.  Linelists also
		  available as text table


From - Fri Jun 20 20:55:58 2003
X-UIDL: 3e5baf650000114a
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5KIteN0011971
	for <ucd-outgoing@mercury.hq.eso.org>; Fri, 20 Jun 2003 20:55:40 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5KIteZR011970
	for ucd-outgoing; Fri, 20 Jun 2003 20:55:40 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5KItbN0011952;
	Fri, 20 Jun 2003 20:55:37 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5KItaP19935;
	Fri, 20 Jun 2003 20:55:36 +0200 (MEST)
Received: from nrao.edu(192.33.115.2) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA_6aO7M; Fri, 20 Jun 03 20:55:35 +0200
Received: from polaris.cv.nrao.edu (polaris.cv.nrao.edu [192.33.115.101])
	by cv3.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h5KItVP26707;
	Fri, 20 Jun 2003 14:55:31 -0400
Received: from oak (oak.aoc.nrao.edu [146.88.1.137])
	by polaris.cv.nrao.edu (8.11.6/8.11.6) with ESMTP id h5KItUV29412;
	Fri, 20 Jun 2003 14:55:30 -0400
Date: Fri, 20 Jun 2003 12:55:29 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: Sebastien Derriere <derriere@newb6.u-strasbg.fr>
cc: ucd@ivoa.net, <dm@ivoa.net>, <dal@ivoa.net>
Subject: Re: UCD for SIAP
In-Reply-To: <3EF329A0.6B013D17@astro.u-strasbg.fr>
Message-ID: <Pine.LNX.4.44.0306201049390.23640-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.2, required 7,
	EMAIL_ATTRIBUTION, IN_REP_TO, SPAM_PHRASE_00_01, USER_AGENT_PINE)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
Status:   

Sebastien -

Good - we agree I think.  This is exactly the point I was trying to
make about data models and UCDs.  The attributes of formal data models
need to be defined precisely and unambiguously.  The attributes of
different data models need to be uniquely identified by some means, e.g.,
a globally unique name or reference (e.g., a form of UCD), a namespace
(e.g., our temporary VOX namespace), or some hierarchical structure as
in IDHA.  The attributes of different data models, although they need to
be distinguished from one another, may well share the same fundamental
type, and a UCD could be used to express this.

Using different approaches to naming data model attributes and types (UCDs),
as I think you are suggesting below, is one way to solve the problem.
This provides both the precision required to identify DM attributes, and the
means to associate elements of different data models for interoperability.

The only problem I see with this is that we would like flexibility in
how we represent data models and metadata.  Mapping DM attributes into
the columns of a flat table, as in SIA or in a FITS header, is convenient
and can simplify representations, up to a point.  If datasets get complex
enough then eventually one needs more structure and an approach such as
IDHA or HDX may be called for.  In many cases the simpler representation
is adequate.  It would be good if the underlying mechanisms, such as UCDs
and how we define data models, were flexible enough to permit a variety
of such representations.

If we map the attributes of a DM into table columns and we do NOT use the
UCD to identify the DM attribute, then we need another tag of some sort
for this purpose.  This would be no problem in XML, but we would have
the nuisance of carrying along an additional tag separate from the UCD.
In VOTable this would give us NAME, ID, UCD, plus a new tag for the
formal DM attribute assocation (conceivably ID could be used for this
purpose but it already has other uses).  In a representation such as
FITS, (e.g., if we try to represent VO data in FITS), then it is harder.
In this case one might want to use the comment field of a FITS keyword
to contain something like a UCD:  keyword = value / UCD.  I am not saying
we necessarily want to do this, but it is an example of representation
flexibility and it would be good if our scheme could extend to this level.

If we DO use the UCD to carry this additional meaning, then the global
UCD namespace could include both formal DM attribute names, and the more
fundamental types used to associate different data elements as at present.
UCDs would then provide a global naming index, with a single name (the
UCD) being sufficient to carry all this meaning.  Given the UCDs and
an understanding of the associated DM (stored separately) we would then
be able to recognize that different metadata elements (table columns in
this case) are associated, define and use an XML schema to verify the
integrity of the DM subset in these columns, use semantic relationships
for inference, and so forth.

In this case what we would do is use the UCD tag in a representation to
convey the data model attribute name, uniquely identifying both the data
model and the attribute of the data model.  The formal definition of the DM
would then define each attribute of the DM, ** giving for each attribute
the UCD type of the attribute **.  If this UCD type is elemental then we
would have the desired interoperability, and the means to associate and
compare similar data elements.  UCDs would thus provide the metadata "glue"
to link related concepts such as fundamental quantities and data models,
making possible a uniform representation for both.

To summarize, UCDs or something like them can play a key role to structure
and link fundamental metadata and data models.  The issue has already come
up in interfaces like SIA and IDHA.  Can we come up with something which is
sufficiently powerful and general to provide both types of representations?

	- Doug



On Fri, 20 Jun 2003, Sebastien Derriere wrote:
> Doug Tody wrote:
> > 
> > The key problem I see with trying to use existing UCDs is that historically
> > UCDs have been used primarily as fuzzy tags to link similar fields in
> > catalogs.  In data access metadata such as is introduced in SIA we are
> > using UCDs to identify the fields of a formal data model.  Here the tag
> > is not fuzzy at all, linking similar fields of unrelated catalogs, rather
> > it is a link to a field of a formally defined data model.  Precision is
> > important for these data models - we are precisely defining attributes
> > of the data model.
> > 
> > We should formally define data models such as spectralBandpass or WCS
> > and define, as part of the data model, the UCD tag used to identify an
> > attribute of the data model.  When we represent a data model as a set of
> > related columns in a table, or as an entity struct in XML (as in IDHA or
> > HDX), we will use the UCDs to formally type the data model attributes so
> > that programs can use them unambiguously, so that we can use XML Schemas
> > for automated validation, and so forth.
> 
>   Hello,
> 
>   The primary goal of UCDs is to ensure interoperability between
> heterogeneous datasets. That's why they have been defined to some
> "reasonable" level of precision (what you call fuzziness).
>   Internal attributes of a formally defined data model can be defined
> at any level of precision, and have their own names. But you can
> have *in addition* a UCD attached to every attribute (see the case 
> of the IDHA model). Those UCD can ensure interoperability between
> different data models, and between data models and datasets. 
>   The names of the attributes can not a priori ensure this task,
> because nothing prevents from having the same concept named 
> differently in different models.
> 
> Sebastien.

From - Sat Jun 21 02:15:59 2003
X-UIDL: 3e5baf650000114e
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <mdolensk@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5L0DNgt016944
	for <ucd-outgoing@mercury.hq.eso.org>; Sat, 21 Jun 2003 02:13:23 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5L0DNQ6016943
	for ucd-outgoing; Sat, 21 Jun 2003 02:13:23 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5L0DIgt016922;
	Sat, 21 Jun 2003 02:13:18 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5L0DIo01929;
	Sat, 21 Jun 2003 02:13:18 +0200 (MEST)
Received: from email.noao.edu(140.252.1.54) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAANaaXd; Sat, 21 Jun 03 02:13:17 +0200
X-SpamCatcher-Score:   1 [X]
Received: from [209.155.156.44] (account tody HELO lepus.tuc.noao.edu)
  by noao.edu (CommuniGate Pro SMTP 4.1b8)
  with ESMTP id 7787223; Fri, 20 Jun 2003 17:13:14 -0700
Date: Fri, 20 Jun 2003 18:13:10 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@localhost.localdomain
To: Roy Williams <roy@cacr.caltech.edu>
cc: ucd@ivoa.net, <dm@ivoa.net>, IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: UCD for SIAP
In-Reply-To: <02f601c3350b$83283ab0$6b91d783@cacr.caltech.edu>
Message-ID: <Pine.LNX.4.44.0306201738200.7921-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
Status:   

Roy -

I don't think we are actually very far apart on this.  The main thing I
am trying to do is determine how to deal with data models in DAL headers
such as for SIA.

An SIA contains two types of information all collected together in a flat
votable:

    - Attributes which are part of the SIA interface (e.g., AccessReference).

    - Attributes which are part of formal data models which are mapped
      into the columns of the table, e.g., BandPass, WCS.  The current
      SIA defines these as part of the interface but in principle what
      you see represents formally defined data models which are defined
      external to SIA.

The SIA interface attributes could use standard UCDs (e.g., DATA_LINK)
since the SIA interface is a controlled namespace and we can precisely
defined what UCDs mean when present in an SIA votable.

The data model attributes are something different.  In general we might
want to use any set of data models to define the attributes of a dataset
described by a DAL service.  A data model like BandPass or WCS should stand
on its own, and be reusable in various contexts, e.g., any DAL service,
or any VOTable (or VO-in-FITS) representation of a dataset.  If we map
the attributes of a data model into the columns of a VOtable (or the
keywords of a FITS header) then the attributes need to be uniquely named
so that they don't get confused with one another, so that we can verify
data model integrity (no missing required attributes), and so forth.

Some mechanism is needed to uniquely and unambiguously identify the
attributes of a data model in such a context.  It doesn't have to be the
UCD, but this seems to be a natural extension of the UCD concept and usage.

Your suggested UCDs for BandPass are close to what is needed, since they
are basically direct one-to-one mappings of the data model attributes.
We just need to go one step further and define a formal relationship between
such UCDs and data model attributes.

I went back and looked at your slides from the IVOA workshop again to see
what I could learn.  The summary slide goes like this:

    UCD is inherently fuzzy
    UCD is a description, not a unique name
	...
    UCD will be eventually replaced by
	"pointers into data model"

It seems to me this is exactly what we have been talking about.
Conventional UCDs are fuzzy tags used to associate similar data elements.
If we use a UCD to tag an attribute of a data model this UCD is a **pointer
into a data model**.  If we then go and look up the definition of this
data model, it may state that the pointed-to DM attribute in turn has a
UCD defining its "type", allowing it to be associated with other similar
data elements in the more conventional UCD way.

It is not clear if UCDs really need to be replaced by a new scheme
providing pointers into data models - they come pretty close to this
already.  This is what SIA is trying to do; some such scheme is needed
to represent data models in DAL protocols like SIA, even for these early
versions.

Well that's it for me for a while as I am about to leave on travel.
I do think we are close to resolving this, and maybe even taking a
step forward towards integrating data models and metadata via UCDs.
We would like to do something more standard for these new "data model"
UCDs in the upcoming DAL interfaces.

	- Doug






On Tue, 17 Jun 2003, Roy Williams wrote:

> One of my actions as part of the UCD steering committee is to work with the
> "VOX" new UCDs that were created for the SIAP protocol.
> 
> Below, I have listed all of the VOX UCDs that could find in the SIAP
> definition, with a little bit of the description. I have tried to find an
> equivalent in the standard UCD set, and in many cases was successful. For
> example is there a reason for VOX:Image_AccessReference as a new UCD, why
> can't we simply use DATA_LINK from the existing set? This is why it says
> "**existing: DATA_LINK" for that entry.
> 
> Of course, there will a revision when we steel on the "base+modifier" scheme
> for UCD that we decided in Cambridge.
> 
> Please can some of you look at the suggested equivalents fron the exisiting
> set, and the suggested new UCDs in the listing below? We gain
> interoperability from reusing and following the existing tree -- but do we
> lose anything?
> 
> Thenk You
> Roy
> 
> --------
> Caltech Center for Advanced Computing Research
> roy@cacr.caltech.edu
> 626 395 3670
> 
> VOX:Image_Title
> ** existing: ID_IMAGE
> containing a short (usually one line) description of the image.
> 
> VOX:Image_MJDateObs
> ** existing: TIME_DATE
> with datatype="double", representing the mean modified Julian date of the
> observation.
> 
> VOX:Image_Naxes
> ** new: POS_TRANSF_WCS_NAXES
> specifying the number of image axes.
> 
> VOX:Image_Naxis
> ** new: POS_TRANSF_WCS_NAXIS
> NOTE: Can a UCD refer to an array like this?
> with the array value giving the length in pixels of each image axis.
> 
> VOX:Image_Scale
> ** new: POS_TRANSF_WCS_CDELT
> NOTE: Can a UCD refer to an array like this?
> with the array value giving the scale in degrees per pixel of each image
> axis.
> 
> VOX:Image_Format
> ** new: DATA_TYPE_MIME
> specifying the MIME-type of the object associated with the image acref,
> e.g.,  image/fits", "text/html", and so forth.
> 
> VOX:STC_CoordRefFrame
> ** existing: ID_FRAME
> representing the coordinate system reference frame, selected from "ICRS",
> "FK5", "FK4", "ECL", "GAL", and "SGAL".
> 
> VOX:STC_CoordEquinox
> ** existing: TIME_EQUINOX
> representing the Equinox (not required for ICRS) of the coordinate system
> used for the image world coordinate system (WCS).
> 
> VOX:WCS_CoordProjection
> ** new: POS_TRANSF_WCS_CTYPE
> with the array value being the three-character code ("TAN", "ARC", "SIN",
> etc.)
> 
> VOX:WCS_CoordRefPixel
> ** new: POS_TRANSF_WCS_CRPIX
> with the array value specifying the image pixel coordinates of the WCS
> 
> reference pixel. This is identical to "CRPIX" in FITS WCS.
> 
> VOX:WCS_CoordRefValue
> ** new: POS_TRANSF_WCS_CRVAL
> with the array value specifying the world coordinates of the WCS reference
> pixel. This is identical to "CRVAL" in FITS WCS.
> 
> VOX:WCS_CDMatrix
> ** new: POS_TRANSF_WCS_CD
> with the array (matrix) value specifying the WCS CD matrix.
> 
> VOX:BandPass_ID
> ** existing: INST_FILTER_CODE
> identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.).
> 
> VOX:BandPass_Unit
> ** existing: UNITS -- but should be GROUPED with Bandpass
> identifying the units used to represent spectral values, selected from
> "meters", "hertz", and "keV".
> 
> VOX:BandPass_RefValue
> ** new: INST_FILTER_REF
> specifying the characteristic (reference) frequency, wavelength, or energy
> for the bandpass model.
> 
> VOX:BandPass_HiLimit
> ** new: INST_FILTER_MAX
> specifying the upper limit of the bandpass.
> 
> VOX:BandPass_LoLimit
> ** new: INST_FILTER_MIN
> specifying the lower limit of the bandpass.
> 
> VOX:Image_PixFlags
> ** existing: CODE_MISC
> specifying the type of processing done by the image service to produce an
> output image pixel. The string value should be formed from some
> 
> combination of the following character codes: C, F, X, Z, V
> 
> VOX:Image_AccessReference
> ** existing: DATA_LINK
> specifying the URL to be used to access or retrieve the image.
> 
> VOX:Image_AccessRefTTL
> ** existing: TIME_DELAY
> specifying the minimum time to live in seconds of the access reference.
> 
> VOX:Image_FileSize
> ** new: DATA_SIZE
> representing the actual or estimated size of the encoded image in bytes (not
> pixels!).
> 
> 

From - Thu Jun 26 18:43:17 2003
X-UIDL: 3e5baf6500001229
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5QGea0T005679
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 26 Jun 2003 18:40:36 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5QGeajI005678
	for dal-outgoing; Thu, 26 Jun 2003 18:40:36 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5QGeQ0T005618
	for <dal@ivoa.net>; Thu, 26 Jun 2003 18:40:26 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.6+Sun/8.11.6) with ESMTP id h5QGfrD15250
	for <dal@ivoa.net>; Thu, 26 Jun 2003 18:41:53 +0200 (MEST)
Message-ID: <3EFB21D6.8010106@eso.org>
Date: Thu, 26 Jun 2003 18:39:50 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Re: Simple Spectral Access use cases
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
Status:   

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
 
<p>Hi Doug, </p>
<p>Better late than never ;-) </p>
<blockquote type="CITE">Simple Spectral Access Use Cases 
  <p>Data Providers (e.g., data centers, archives) </p>
  <p>&nbsp;&nbsp;&nbsp; - Data provider name</p>
</blockquote>
 &nbsp;&nbsp;&nbsp; ESO/ST-ECF&nbsp;archive 
<blockquote type="CITE">&nbsp;&nbsp;&nbsp; - Spectral data collections from this source</blockquote>
  
<blockquote type="CITE">&nbsp;&nbsp;&nbsp; - Characteristics of data (number of spectra,
size, irregularly sampled, <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.) 
  <p>&nbsp;&nbsp;&nbsp; - Current data storage format </p>
  <p>&nbsp;&nbsp;&nbsp; - Is the data available online? </p>
  <p>&nbsp;&nbsp;&nbsp; - Other comments <br>
&nbsp;</p>
</blockquote>
  
<table border="1" cols="4" width="100%" nosave="">
 <tbody>
    <tr>
 <td><br>
      </td>
  <td>Number of science spectra</td>
  <td>Storage</td>
  <td>Availability</td>
 </tr>
  <tr>
 <td>HST/FOS</td>
  <td>16058</td>
  <td>FITS</td>
  <td>Worldwide, after a one-year proprietary period, via request handling.&nbsp; 
On-the-fly re-calibration possible</td>
 </tr>
  <tr>
 <td>HST/GHRS</td>
  <td>12340</td>
  <td>FITS</td>
  <td>see above</td>
 </tr>
  <tr>
 <td>HST/STIS</td>
  <td>35766</td>
  <td>FITS</td>
  <td>see above<br>
      </td>
 </tr>
  <tr>
 <td>ESO/FORS1+2</td>
  <td>14721</td>
  <td>FITS</td>
  <td>ESO member states only, , after a one-year proprietary period, via request
handling.&nbsp;</td>
 </tr>
  <tr>
 <td>ESO/ISAAC</td>
  <td>66274</td>
  <td>FITS</td>
  <td>see above</td>
 </tr>
  <tr>
 <td>ESO/VIMOS</td>
  <td>6754</td>
  <td>FITS</td>
  <td>see above</td>
 </tr>
  <tr>
 <td>ESO/UVES</td>
  <td>50024</td>
  <td>FITS</td>
  <td>see above</td>
 </tr>
  <tr>
 <td>ESO/CES</td>
  <td>9272</td>
  <td>FITS</td>
  <td>see above</td>
 </tr>
  <tr>
 <td>ESO/EFOSC2</td>
  <td>11054</td>
  <td>FITS</td>
  <td>see above</td>
 </tr>
  <tr>
 <td>ESO/EMMI</td>
  <td>30332</td>
  <td>FITS</td>
  <td>see above</td>
 </tr>
  <tr>
 <td>ESO/HARPS<br>
      </td>
  <td>-<br>
      </td>
  <td><br>
      </td>
  <td>coming soon<br>
      </td>
 </tr>
    <tr>
      <td valign="top">ESO/GIRAFFE<br>
      </td>
      <td valign="top">-<br>
      </td>
      <td valign="top"><br>
      </td>
      <td valign="top">coming soon<br>
      </td>
    </tr>
 
  </tbody>
</table>
  
<p>Furthermore, the archive has a copy of the NICMOS and ACS grism data and
there is also a WFI grism which isn't used very often, but all this is on-line
as well.<br>
</p>
<p>These values are all snapshots of the present situation. Every day, more
frames are collected.<br>
<br>
</p>
<p>Raw data of echelle and multi object spectroscopy are stored as 2d FITS
images. <br>
<br>
 </p>
<blockquote type="CITE">&nbsp; <br>
Data Consumers (e.g., analysis packages, e.g., VO demonstrations that might 
  <br>
want to add the ability to fetch and display a spectrum) 
  <p>&nbsp;&nbsp;&nbsp; - Name of application, package, demo, etc. </p>
  <p>&nbsp;&nbsp;&nbsp; - Summarize capabilities of software </p>
</blockquote>
<pre wrap=""><!---->FORS1+2: 
most of the spectorscopic modes are supported through the standard FORS 
pipeline. MOS package of MIDAS.

ISAAC:
<!---->most of the spectorscopic modes are supported through the standard ISAAC 
pipeline. MIDAS package for long-slit spectroscopy.

VIMOS:
<!---->MOS reduction by the standard VIMOS pipeline
MOS package of MIDAS (performance )))-: )

<!---->UVES:
most of the spectroscopic modes are supported through the standard UVES 
pipeline.

CES, EFOSC2:
<!---->MIDAS package

<!---->EMMI:
MOS package of MIDAS

HARPS: 
full blown science grade reduction pipeline (reduced spectra will be 
archived as well, but instrument is just under commissioning).

GIRAFFE: 
standard pipeline.

FOS,GHRS,STIS,NICMOS,ACS:
IRAF STSDAS packages for HST instruments
aXe can be used to extract spectra from pairs of direct and grism images (like ACS, FORS2).
</pre>
<br>
<blockquote type="CITE"> 
  <p>&nbsp;&nbsp;&nbsp; - Desired characteristics of input data </p>
  <p>&nbsp;&nbsp;&nbsp; - Desired input data format or formats (e.g., graphics, FITS, XML) 
  </p>
  <p>&nbsp;&nbsp;&nbsp; - Other comments </p>
  <p>General Comments</p>
</blockquote>
 <br>
AVO is working on the on-the-fly extraction of spectra from pairs of direct/grism
images from ACS and FORS2.<br>
We are also working on capabilities to express SEDs in VOTable format and
to display them - see demo at IAU in July.<br>
<br>
<br>
Regards,<br>
Benoit Pirenne, Andreas Wicenec, Markus Dolensky<br>
<br>
<pre class="moz-signature" cols="$mailwrapcol">
</pre>
</body>
</html>

From - Mon Jun 30 14:08:20 2003
X-UIDL: 3e5baf6500001266
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5UC6aYZ024003
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 30 Jun 2003 14:06:36 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5UC6aNi024002
	for dal-outgoing; Mon, 30 Jun 2003 14:06:36 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5UC6WYZ023988
	for <dal@ivoa.net>; Mon, 30 Jun 2003 14:06:32 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5UC6WY00183
	for <dal@ivoa.net>; Mon, 30 Jun 2003 14:06:32 +0200 (MEST)
Received: from isous5.vilspa.esa.es(193.147.153.100) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA6iaWwa; Mon, 30 Jun 03 14:06:31 +0200
Received: from isou53 (isou53 [193.147.153.35])
	by iso.vilspa.esa.es (8.12.9/8.12.9) with SMTP id h5UC6IEg027227;
	Mon, 30 Jun 2003 14:06:18 +0200 (MEST)
Date: Mon, 30 Jun 2003 14:06:18 +0200
From: posuna@iso.vilspa.esa.es
To: Doug Tody <dtody@nrao.edu>
Cc: dal@ivoa.net, ca@iso.vilspa.esa.es, Matteo <Matteo.Guainazzi@esa.int>,
   asalama@iso.vilspa.esa.es
Subject: Re: Simple Spectral Access use cases
Message-Id: <20030630140618.49194ce1.posuna@iso.vilspa.esa.es>
In-Reply-To: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
References: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.9; sparc-sun-solaris2.8)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: posuna@iso.vilspa.esa.es
Status:   

Dear Doug,

here you have our 1-D spectral data as provided by our Archive
Scientists:


XMM-Newton 1D Scpectral Data
----------------------------


     - Data provider name
        ESA XMM Science Data Archive

      - Spectral data collections from this source
	1. automatic pipeline high-resolution spectra for the Reflection
           Grating Spectrometer (RGS) instrument
	2. medium resolution European Photon Imaging Camera (EPIC) spectra for
           each source of the XMM-Newton Serendipitous Source
           Catalogues, both automatically (pipeline) and interactively
           (XSA user interface) produced      - Characteristics of data
           (number of spectra, size, irregularly       
            sampled,nonsampled(as in HE/UV) multiple flux arrays,       
            variance arrays, etc.)

      - Characteristics of data (number of spectra, size, irregularly
        sampled,nonsampled (as in HE/UV) multiple flux arrays,
        variance arrays, etc.)

	1. 
	* Number of spectra (at the end of the mission): ~20000
 	* Size: ~50 KBytes each, ~4096 spectral channels, uniformly and
		  linearly sampled in energy
 	* Resolution: 200-800, in the energy range 0.35-2.5 keV
 	* Data structure: 1-D spectra in CHANNELS/COUNTS
 	* Type of data: background subtracted source and background
		  spectrum for the 1st and 2nd order. Spectra are **not** in
		  physical units, and need an observation dependent transfer
		  matrix(available through the XMM-Newton pipeline products) to
		  be analyzed. Fluxed spectra in physical units available as
		  well, but not usable for quantitative science analysis.

	2. 

 	* Number of spectra (at the end of the mission): ~1500000
 	* Size: ~30-200 KBytes each, 800-4096 spectral channels,
		  uniformly and linearly sampled in energy
 	* Resolution: 20-50, in the energy range 0.35-15 keV
 	* Type of data: source and background spectrum. Spectra are
		  **not** in physical units, and need an observation dependent
		  transfer matrix(**not** available through the XMM-Newton
		  pipeline products) to be analyzed. Plan to provide fluxes
		  spectra in physical units under study * Data structure: 1-D
		  spectra in CHANNELS/COUNTS * Tables: fluxes (in 5 different
		  energy bands), hardness ratios for each individual source

     - Current data storage format
        FITS

      - Is the data available online?
        Yes:
        a) Through a User Interface at:
           http://xsa.vilspa.esa.es/xsa/
        b) Through HTTP directly at:
           http://xsa.vilspa.esa.es:8080/aio/doc/   


      - Other comments



ISO 1D Spectral Data
--------------------

 

    - Data provider name
        ESA ISO Science Data Archive

      - Spectral data collections from this source
        ISO Data Archive (IDA)

      - Characteristics of data (number of spectra, size, irregularly
        sampled,nonsampled (as in HE/UV) multiple flux arrays,
        variance arrays, etc.)

        ~10,000 files, containing spectra at resolutions ranging
         from 40 to 30,000, in the wavelength range of 2.4 to 197
	 micron. Irregularly sampled. File size average 700 KB
	 (compressed).

      - Current data storage format
        FITS

      - Is the data available online?
        Yes:
        a) Through a User Interface at:
            http://www.iso.vilspa.esa.es/ida/
        b) Through HTTP directly at:
          http://pma.iso.vilspa.esa.es:8080/jsp/product.jsp?obsno=<>  


      - Other comments


Cheers,

Pedro.



-- 

Pedro Osuna Alcalaya


SOFTWARE Development Group
XMM-Newton Science Archive				
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314  				

European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727 
E-28080 Villafranca del Castillo
MADRID - SPAIN




On Wed, 18 Jun 2003 21:14:28 -0600 (MDT)
Doug Tody <dtody@nrao.edu> wrote:

> At the IVOA meeting in Cambridge a few weeks ago, one of the highest
> priority projects identified for the DAL working group was to define a
> "simple spectral access" protocol for accessing 1D spectra and SEDs.
> 
> To help plan this effort it would help to get a better idea of how
> such an interface would initially be used.  If you think you or your
> institution might provide 1D spectral data or SEDs to the VO, or might
> provide software to use such data provided by the VO (e.g., as an
> addition to an existing VO demo or by interfacing some analysis
> application), please fill in the following form and return it to
> dal@ivoa.net.  Note doing so is not a committment to actually do any
> work!  We mainly just want to get a better idea of what spectral data
> collections are out there, to help design the spectral data interface.
>  Thanks very much for your help with this.
> 
> Doug Tody (dtody@nrao.edu), Markus Dolensky (Markus.Dolensky@eso.org)
> 
> 
> Simple Spectral Access Use Cases
> 
> Data Providers (e.g., data centers, archives)
> 
>     - Data provider name
> 
>     - Spectral data collections from this source
> 
>     - Characteristics of data (number of spectra, size, irregularly
>     sampled,
>       nonsampled (as in HE/UV) multiple flux arrays, variance arrays,
>       etc.)
> 
>     - Current data storage format
> 
>     - Is the data available online?
> 
>     - Other comments
> 
> 
> Data Consumers (e.g., analysis packages, e.g., VO demonstrations that
> might want to add the ability to fetch and display a spectrum)
> 
>     - Name of application, package, demo, etc.
> 
>     - Summarize capabilities of software
> 
>     - Desired characteristics of input data
> 
>     - Desired input data format or formats (e.g., graphics, FITS, XML)
> 
>     - Other comments
> 
> 
> General Comments 
> 
> 



From - Mon Jun 30 14:58:20 2003
X-UIDL: 3e5baf650000126d
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5UCuQLp009813
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 30 Jun 2003 14:56:26 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h5UCuQGc009810
	for dal-outgoing; Mon, 30 Jun 2003 14:56:26 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h5UCuJLp009787
	for <dal@ivoa.net>; Mon, 30 Jun 2003 14:56:19 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h5UCuJi02704
	for <dal@ivoa.net>; Mon, 30 Jun 2003 14:56:19 +0200 (MEST)
Received: from isous5.vilspa.esa.es(193.147.153.100) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAWzaWrf; Mon, 30 Jun 03 14:56:18 +0200
Received: from isou53 (isou53 [193.147.153.35])
	by iso.vilspa.esa.es (8.12.9/8.12.9) with SMTP id h5UCu6Eg028625;
	Mon, 30 Jun 2003 14:56:07 +0200 (MEST)
Date: Mon, 30 Jun 2003 14:56:06 +0200
From: posuna@iso.vilspa.esa.es
To: dtody@nrao.edu
Cc: dal@ivoa.net, ca@iso.vilspa.esa.es, Matteo.Guainazzi@esa.int,
   asalama@iso.vilspa.esa.es
Subject: Re: Simple Spectral Access use cases
Message-Id: <20030630145606.0370f687.posuna@iso.vilspa.esa.es>
In-Reply-To: <20030630140618.49194ce1.posuna@iso.vilspa.esa.es>
References: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
	<20030630140618.49194ce1.posuna@iso.vilspa.esa.es>
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.9; sparc-sun-solaris2.8)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: posuna@iso.vilspa.esa.es
Status:   

Dear Doug,

there was a small typo in one of the URLs in my previous missage. Please
use this instead.


Here you have our 1-D spectral data as provided by our Archive
 Scientists:


 XMM-Newton 1D Scpectral Data
 ----------------------------


      - Data provider name
         ESA XMM-Newton Science Data Archive

      - Spectral data collections from this source
 	1. automatic pipeline high-resolution spectra for the Reflection
            Grating Spectrometer (RGS) instrument
 	2. medium resolution European Photon Imaging Camera (EPIC)
	   spectra for each source of the XMM-Newton Serendipitous
	   Source Catalogues, both automatically (pipeline) and
	   interactively (XSA user interface) produced 


      - Characteristics of data (number of spectra, size, irregularly
         sampled,nonsampled (as in HE/UV) multiple flux arrays,
         variance arrays, etc.)

 	1. 
 	* Number of spectra (at the end of the mission): ~20000
  	* Size: ~50 KBytes each, ~4096 spectral channels, uniformly and
 		  linearly sampled in energy
  	* Resolution: 200-800, in the energy range 0.35-2.5 keV
  	* Data structure: 1-D spectra in CHANNELS/COUNTS
  	* Type of data: background subtracted source and background
 		  spectrum for the 1st and 2nd order. Spectra are **not** in
 		  physical units, and need an observation dependent transfer
 		  matrix(available through the XMM-Newton pipeline products) to
 		  be analyzed. Fluxed spectra in physical units available as
 		  well, but not usable for quantitative science analysis.

 	2. 

  	* Number of spectra (at the end of the mission): ~1500000
  	* Size: ~30-200 KBytes each, 800-4096 spectral channels,
 		  uniformly and linearly sampled in energy
  	* Resolution: 20-50, in the energy range 0.35-15 keV
  	* Type of data: source and background spectrum. Spectra are
 		  **not** in physical units, and need an observation dependent
 		  transfer matrix(**not** available through the XMM-Newton
 		  pipeline products) to be analyzed. Plan to provide fluxes
 		  spectra in physical units under study * Data structure: 1-D
 		  spectra in CHANNELS/COUNTS * Tables: fluxes (in 5 different
 		  energy bands), hardness ratios for each individual source

      - Current data storage format
         FITS

       - Is the data available online?
         Yes:
         a) Through a User Interface at:
            http://xmm.vilspa.esa.es/xsa/
         b) Through HTTP directly at:
            http://xsa.vilspa.esa.es:8080/aio/doc/   


       - Other comments



 ISO 1D Spectral Data
 --------------------

  

     - Data provider name
         ESA ISO Science Data Archive

       - Spectral data collections from this source
         ISO Data Archive (IDA)

       - Characteristics of data (number of spectra, size, irregularly
         sampled,nonsampled (as in HE/UV) multiple flux arrays,
         variance arrays, etc.)

         ~10,000 files, containing spectra at resolutions ranging
          from 40 to 30,000, in the wavelength range of 2.4 to 197
 	 micron. Irregularly sampled. File size average 700 KB
 	 (compressed).

       - Current data storage format
         FITS

       - Is the data available online?
         Yes:
         a) Through a User Interface at:
             http://www.iso.vilspa.esa.es/ida/
         b) Through HTTP directly at:
           http://pma.iso.vilspa.esa.es:8080/jsp/product.jsp?obsno=<>  


       - Other comments


 Cheers,

 Pedro.



 -- 

 Pedro Osuna Alcalaya


 SOFTWARE Development Group
 XMM-Newton Science Archive				
 e-mail: Pedro.Osuna@esa.int
 Tel + 34 91 8131314  				

 European Space Agency
 VILLAFRANCA Satellites Tracking Station
 P.O. Box 50727 
 E-28080 Villafranca del Castillo
 MADRID - SPAIN







> On Wed, 18 Jun 2003 21:14:28 -0600 (MDT)
> Doug Tody <dtody@nrao.edu> wrote:
> 
> > At the IVOA meeting in Cambridge a few weeks ago, one of the highest
> > priority projects identified for the DAL working group was to define
> > a"simple spectral access" protocol for accessing 1D spectra and
> > SEDs.
> > 
> > To help plan this effort it would help to get a better idea of how
> > such an interface would initially be used.  If you think you or your
> > institution might provide 1D spectral data or SEDs to the VO, or
> > might provide software to use such data provided by the VO (e.g., as
> > an addition to an existing VO demo or by interfacing some analysis
> > application), please fill in the following form and return it to
> > dal@ivoa.net.  Note doing so is not a committment to actually do any
> > work!  We mainly just want to get a better idea of what spectral
> > data collections are out there, to help design the spectral data
> > interface.
> >  Thanks very much for your help with this.
> > 
> > Doug Tody (dtody@nrao.edu), Markus Dolensky
> > (Markus.Dolensky@eso.org)
> > 
> > 
> > Simple Spectral Access Use Cases
> > 
> > Data Providers (e.g., data centers, archives)
> > 
> >     - Data provider name
> > 
> >     - Spectral data collections from this source
> > 
> >     - Characteristics of data (number of spectra, size, irregularly
> >     sampled,
> >       nonsampled (as in HE/UV) multiple flux arrays, variance
> >       arrays, etc.)
> > 
> >     - Current data storage format
> > 
> >     - Is the data available online?
> > 
> >     - Other comments
> > 
> > 
> > Data Consumers (e.g., analysis packages, e.g., VO demonstrations
> > that might want to add the ability to fetch and display a spectrum)
> > 
> >     - Name of application, package, demo, etc.
> > 
> >     - Summarize capabilities of software
> > 
> >     - Desired characteristics of input data
> > 
> >     - Desired input data format or formats (e.g., graphics, FITS,
> >     XML)
> > 
> >     - Other comments
> > 
> > 
> > General Comments 
> > 
> > 
> 
> 
> 


-- 

Pedro Osuna Alcalaya


SOFTWARE Development Group
XMM-Newton Science Archive				
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314  				

European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727 
E-28080 Villafranca del Castillo
MADRID - SPAIN

From - Wed Jul  2 08:53:22 2003
X-UIDL: 3e5baf650000141d
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h626o5Pl012350
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 2 Jul 2003 08:50:05 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h626o5Z3012348
	for dal-outgoing; Wed, 2 Jul 2003 08:50:05 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h626nsPl012243
	for <dal@ivoa.net>; Wed, 2 Jul 2003 08:49:58 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h626nlU27290
	for <dal@ivoa.net>; Wed, 2 Jul 2003 08:49:47 +0200 (MEST)
Received: from esacom49.vilspa.esa.es(131.176.170.2) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAc1aGs1; Wed, 2 Jul 03 08:49:46 +0200
Received: from esacom65.vilspa.esa.int (esacom65.vilspa.esa.int [131.176.121.32])
	by esacom49.vilspa.esa.es (8.12.9/8.12.9/ESA-External-v3.0) with ESMTP id h626ne46022138;
	Wed, 2 Jul 2003 08:49:40 +0200 (MET DST)
Received: from vilspamail2.vilspa.esa.int (vilspamail2.vilspa.esa.int [131.176.121.241])
	by esacom65.vilspa.esa.int (8.12.9/8.12.9/ESA-Internal-v3.2) with SMTP id h626neug020387;
	Wed, 2 Jul 2003 08:49:40 +0200 (MET DST)
Received: by vilspamail2.vilspa.esa.int(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256D57.00254878 ; Wed, 2 Jul 2003 08:47:13 +0200
X-Lotus-FromDomain: ESA
From: Enrique.Solano@esa.int
To: dtody@nrao.edu, dal@ivoa.net
cc: esm@laeff.esa.es, raul@laeff.esa.es
Message-ID: <C1256D57.0025468A.00@vilspamail2.vilspa.esa.int>
Date: Wed, 2 Jul 2003 08:48:46 +0200
Subject: Re: Simple Spectral Access use cases
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Enrique.Solano@esa.int
Status:   

Dear Doug,

Please find below the requested information:

   Simple Spectral Access Use Cases

    # Data Providers (e.g., data centers, archives)

       - Data provider name: INTA/LAEFF

       - Spectral data collections from this source: INES (IUE Newly-Extracted
   Spectra)

       - Characteristics of data (number of spectra, size, irregularly sampled,
         nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.)

          + Total number of spectra: 110000
          + Total number of objects: 9500
          + Satellite lifetime: 18.6 years (Jan 1978 - Sep 1996)
          + Wavelength range: 1850-3350 angstroms (Long wavelength
spectrographs)
                           1150-1980 angstroms (Short wavelength spectrograph)
          + Data type:

               * Concatenated high-dispersion echelle 1-D spectra: 35000
spectra.
                 Size: 350Kbytes. Dispersion: 0.2 Angstroms. Non-linear
sampling.

               * Rebinned high-dispersion 1-D spectra (rebinned onto low
dispersion                       wavelength scale): 35000 spectra. Size:
18Kbytes. Linear sampling:
                         --> Long wavelength: 562 pixels @ 2.669 angstroms/pixel
                         --> Short wavelength: 495 pixels @ 1.676
angstroms/pixel

               * Low-dispersion 1-D spectra: 75000 spectra. Size: 18Kbytes.
                  Dispersion: 6 angstroms. Linear sampling:
                         --> Long wavelength: 562 pixels @ 2.669 angstroms/pixel
                         --> Short wavelength: 495 pixels @ 1.676
angstroms/pixel

               * Low-dispersion 2-D spectra: 68000 spectra. Size: 250Kbytes


     - Current data storage format:

               * Concatenated high-disp., rebinned high-disp., low-disp: FITS
binary                     tables. Each binary table contains four columns:
wavelength, absolute                 flux, associated error flux and quality
flag.

               * Low-dispersion 2-D spectra: FITS images.

     - Is the data available online? YES. http://ines.laeff.esa.es/ines/



From - Thu Jul  3 22:21:28 2003
X-UIDL: 3e5baf650000148c
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <owner-metadata@us-vo.org>
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h63KHHTv010654
	for <mdolensk@eso.org>; Thu, 3 Jul 2003 22:17:17 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h63KHH121225
	for <mdolensk@eso.org>; Thu, 3 Jul 2003 22:17:17 +0200 (MEST)
Received: from mercury.cacr.caltech.edu(131.215.145.175) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAPga4CP; Thu, 3 Jul 03 22:17:16 +0200
Received: from mercury.cacr.caltech.edu (localhost [127.0.0.1])
	by mercury.cacr.caltech.edu (8.12.9/8.12.9/Debian-3) with ESMTP id h63KDDHn020813
	for <metadata-list@mercury.cacr.caltech.edu>; Thu, 3 Jul 2003 13:13:38 -0700
Received: (from majordomo@localhost)
	by mercury.cacr.caltech.edu (8.12.9/8.12.9/Debian-3) id h63KDDgi020811
	for metadata-list; Thu, 3 Jul 2003 13:13:13 -0700
X-Authentication-Warning: mercury.cacr.caltech.edu: majordomo set sender to owner-metadata@us-vo.org using -f
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by mercury.cacr.caltech.edu (8.12.9/8.12.9/Debian-3) with ESMTP id h63KBvHn020808
	for <metadata@us-vo.org>; Thu, 3 Jul 2003 13:11:57 -0700
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id h63KDUr7020563
          ; Thu, 3 Jul 2003 22:13:31 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id WAA27158;
	Thu, 3 Jul 2003 22:04:56 +0200 (MET DST)
Date: Thu, 3 Jul 2003 22:04:56 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200307032004.WAA27158@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net, metadata@us-vo.org
Subject: AVO Metadata-tree : Overview and Documentation
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-metadata@us-vo.org
Precedence: bulk
X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.cacr.caltech.edu id h63KDDHn020813
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h63KHHTv010654
Status:   


A new version (1.0) of this document allready sent on these lists before
the Cambridge meeting has been installed yesterday by Mark Allen and I
on the AVO Twiki.
See:
http://www.euro-vo.org/internal/Main/MetadataTree/MetadataTree_v1.txt
and
http://www.euro-vo.org/internal/Main/MetadataTree/annotated_example

This AVO metadata-tree experiment (as a concrete application of the
IDHA data model -http://alinda.u-strasbg.fr/IDHA/lastmodel)
which will again be present in the AVO Sydney demo
is NOT in competition with SIAP. It is just a different experiment
started  in parallel to help  in image metadata exchanging.
We had extensive discussions here at CDS with Doug which show
that we will probably succeed in converging in the future.

The AVO Sydney demo interface is also a client for SIAP servers.

Regards
François Bonnarel

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Wed Aug  6 21:56:03 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h76JrA5L000798
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 6 Aug 2003 21:53:10 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h76JrAc9000795
	for dal-outgoing; Wed, 6 Aug 2003 21:53:10 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h76Jr15L000640;
	Wed, 6 Aug 2003 21:53:01 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h76Jr0719997;
	Wed, 6 Aug 2003 21:53:00 +0200 (MEST)
Received: from head-cfa.cfa.harvard.edu(131.142.41.8) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAGbaadN; Wed, 6 Aug 03 21:52:59 +0200
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head-cfa.cfa.harvard.edu (8.12.8p1/8.12.8) with ESMTP id h76JqvD9026800;
	Wed, 6 Aug 2003 15:52:57 -0400 (EDT)
From: Arnold Rots <arots@head-cfa.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id h76JqvRO009174;
	Wed, 6 Aug 2003 15:52:57 -0400 (EDT)
Message-Id: <200308061952.h76JqvRO009174@xebec.cfa.harvard.edu>
Subject: Space-Time metadata
To: dm@ivoa.net, dal@ivoa.net, registry@ivoa.net, voql@ivoa.net,
   votable@ivoa.net
Date: Wed, 6 Aug 2003 15:52:57 -0400 (EDT)
CC: cfa_nvo@head-cfa.cfa.harvard.edu
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Arnold Rots <arots@head-cfa.cfa.harvard.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

I put pdf and ps copies of my IAU poster on my website:

	http://hea-www.harvard.edu/~arots/nvometa/STC.pdf
	http://hea-www.harvard.edu/~arots/nvometa/STC.ps

be careful, it's 36 x 56 inches (91.5 x 142.2 cm).

Also, I made an update to one of the schemas (including a reference
direction to the time frame element).  The schemas are at:

	http://hea-www.harvard.edu/~arots/nvometa/stc.xsd
	http://hea-www.harvard.edu/~arots/nvometa/coords.xsd
	http://hea-www.harvard.edu/~arots/nvometa/region.xsd

To summarize: these schemas specify the metadata structure for the
interwined space, time, redshift, and spectral coordinates, describing
the coordinate space volume taken up by a dataset, catalog, query, or
resource.

Apologies if you get more than one copy of this message; it did not
seem to fit one single mailing list.

  - Arnold

--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From owner-dal@eso.org  Fri Aug  8 11:25:24 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h789P094011621
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 8 Aug 2003 11:25:01 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h789P0vh011619
	for dal-outgoing; Fri, 8 Aug 2003 11:25:00 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h789Ou94011593
	for <dal@ivoa.net>; Fri, 8 Aug 2003 11:24:56 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h789RLx18871
	for <dal@ivoa.net>; Fri, 8 Aug 2003 11:27:21 +0200 (MEST)
Message-ID: <3F336D13.8010402@eso.org>
Date: Fri, 08 Aug 2003 11:27:47 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: IVOA Data Access Layer <dal@ivoa.net>
Subject: Survey among Spectral Data Providers and Consumers
References: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear All,

here are the results of a little survey among spectral data providers and 
consumers:

http://www.ivoa.net/twiki/bin/view/IVOA/SsaSurvey

The results will help to design a Simple Spectral Access (SSA) protocol for 
accessing 1D spectra and SEDs. Of course, the summary is only as complete as 
the response we've received. Thanks a lot to all who took the time to answer to 
our questions!

Info about further data providers and consumers is most welcome.

With best regards,
Markus

+---
| Markus Dolensky   Mailto:Markus.Dolensky@eso.org
| AVO Technical Lead          Web: www.euro-vo.org
| Voice: ++49 89 32006/261  Fax: ++49 89 32006/480
+---

From owner-dal@eso.org  Wed Aug 27 10:05:14 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h7R81LIt003611
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 27 Aug 2003 10:01:21 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h7R81LpY003609
	for dal-outgoing; Wed, 27 Aug 2003 10:01:21 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h7R80NIt003151
	for <dal@ivoa.net>; Wed, 27 Aug 2003 10:00:34 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h7R80ML11837
	for <dal@ivoa.net>; Wed, 27 Aug 2003 10:00:22 +0200 (MEST)
Received: from mail.mtk.nao.ac.jp(133.40.4.4) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAJDa4gx; Wed, 27 Aug 03 10:00:20 +0200
Received: from [133.40.208.177] (localhost [127.0.0.1])
	by mail.mtk.nao.ac.jp (8.9.3p2/3.7W00121514) with ESMTP id RAA23516;
	Wed, 27 Aug 2003 17:00:13 +0900 (JST)
Date: Wed, 27 Aug 2003 17:03:32 +0900
From: Honda Satoshi <honda.satoshi@nao.ac.jp>
To: Doug Tody <dtody@nrao.edu>
Subject: Re: Simple Spectral Access use cases
Cc: IVOA Data Access Layer <dal@ivoa.net>
In-Reply-To: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
References: <Pine.LNX.4.44.0306182113230.1534-100000@localhost.localdomain>
Message-Id: <20030827164921.FBF0.HONDA.SATOSHI@nao.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Honda Satoshi <honda.satoshi@nao.ac.jp>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Doug Tody,

It was with sincere apology that I failed to write to you sooner.
These are mainly optical or infrared data.
Please add these data to the list.

With Regards,


Satoshi Honda
National Astronomical Observatory of Japan
JVO team


---
Simple Spectral Access Use Cases

Data Providers (e.g., data centers, archives)

    - Data provider name

	NAOJ/SMOKA 
	(National Astronomical Observatory of Japan / Subaru Mitaka Okayama Kiso Archive)
	http://smoka.nao.ac.jp/

    - Spectral data collections from this source

	Subaru/HDS (extremely high-dispersion optical echelle spectroscopy)
	Subaru/IRCS (low-resolution and echelle spectroscopy from 1-5 microns)
	Subaru/FOCAS (optical longslit and multi-slit spectroscopy over a 6 arcmin field of view)
	Subaru/OHS (low-resolution spectroscopy in the near-infrared)
	Subaru/COMICS (spectroscopy from 8-26 microns)
	OAO/HIDES (extremely high-dispersion optical echelle spectroscopy)
	OAO/SNG (low-resolution optical spectroscopy)

	[OAO : 188cm telescope at Okayama Astronomical Observatory]
	http://www.cc.nao.ac.jp/oao/e/
	[Subaru : 8.2m optical-infrared telescope at the summit of Mauna Kea]
	http://SubaruTelescope.org/

    - Characteristics of data (number of spectra, size, irregularly sampled,
      nonsampled (as in HE/UV) multiple flux arrays, variance arrays, etc.)

		number	size
	HDS	2158	16MB
	IRCS	7546	4MB
	FOCAS	3121	16MB
	OHS	4664	2MB
	COMICS	9902	1.7MB
	HIDES	1390	16MB2
	SNG 	8441	0.3MB

	2003.8.25

    - Current data storage format

	All data are FITS format.

    - Is the data available online?

	Yes
	(To request data, you should register as an SMOKA user.)

    - Other comments
---

From owner-dm@eso.org  Fri Sep 19 19:58:24 2003
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JHuE5x008829
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 19 Sep 2003 19:56:14 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8JHuEnY008828
	for dm-outgoing; Fri, 19 Sep 2003 19:56:14 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8JHte5x008715;
	Fri, 19 Sep 2003 19:55:40 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8JHtec17357;
	Fri, 19 Sep 2003 19:55:40 +0200 (MEST)
Received: from revere.aoc.nrao.edu(146.88.1.15) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAA1jaG5H; Fri, 19 Sep 03 19:55:39 +0200
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id h8JHtZn26253;
	Fri, 19 Sep 2003 11:55:35 -0600
Received: from oak (oak [146.88.1.137])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id h8JHtW72010153;
	Fri, 19 Sep 2003 11:55:32 -0600 (MDT)
Date: Fri, 19 Sep 2003 11:55:32 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: Jonathan McDowell <jcm@head-cfa.cfa.harvard.edu>
cc: dm@ivoa.net, <dal@ivoa.net>
Subject: Re: [SPECTRA] Some thoughts on the spectral model
In-Reply-To: <200309171740.h8HHeMB8010091@urania.cfa.harvard.edu>
Message-ID: <Pine.LNX.4.44.0309191154360.28909-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.1, required 7,
	IN_REP_TO, ITS_LEGAL, SPAM_PHRASE_00_01, USER_AGENT_PINE)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Jonathan -

I hope that others will respond to your message, but I have some comments
along the lines of what we discussed in Victoria.


> As those of you who were at the recent NVO meeting know, I have been
> taking a look at the datasets referred to in the spectral use survey led
> by Doug Tody. Here I note a grab-bag of things that came out of this
> study we should keep in mind for the spectral data model. In general,
> the model for spectra presented earlier covers most of these cases, but
> doesn't have a good place to put things like exposure and response
> information.

Both object spectra and calibration spectra would be useful to have online
with consistent data model support, but our priority should be to support
object spectra from large spectral surveys.  A data model that supports
"typical" spectra surveys (if there is such a thing) will probably also work
for virtual object spectra constructed on the fly, e.g., from spectral
data cubes.  We should address this hopefully simpler problem first
and then perhaps extend the data model to describe calibration spectra.
Calibration spectra can be idiosyncratic hence difficult to describe with
a general data model, at least without making it complex.

Some spectral surveys to look at include SDSS, 2DF, VIRMOS, DEEP2, IUE,
FUSE (note some of these were not included in our spectral survey).


>  7) Although not different from the data model's point of view,
>     I'm particularly concerned by the SDSS spectral FITS files.
>     These have an n x 4 FITS image, where n is the number of
>     wavelength points and the 4 layers are different observables
>     (data, continuum-subtracted data, error, mask). This breaks
>     the FITS paradigm (e.g. BUNIT is meaningless since the 4th
>     plane has different units from the other 3) while using four
>     n x 1 images would have been perfectly legal FITS allowing
>     use of meaninful metadata. SDSS is by far not the only offender
>     in this respect. Data providers will haave to take particular
>     care in describing such datasets to the VO, and I suspect the
>     data will have to be reformatted prior to transfer along the
>     wire if generic VO tools to be developed to operate on
>     spectra are to have a chance at swallowing these data.

The best way to solve this problem is to have our SSA services convert
data from the various proprietary spectral data formats into the data
model we implement in SSA.  We can then return the spectrum data to the
client in simple ascii, XML/VOTable, HTML (for display), or FITS.  In the
latter case would need to invent a FITS format for 1D spectra.  In effect,
equivalent spectra in the SSA spectral data model would be available to
the client in any of these formats.  We also plan to provide a link to
the raw external data file (if available), but it will be most useful
to have the data provider deal with the details of the many different
spectral data formats out there.

	- Doug


From owner-dal@eso.org  Sat Sep 27 14:07:53 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8RC6DoB027234
	for <dal-outgoing@mercury.hq.eso.org>; Sat, 27 Sep 2003 14:06:13 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h8RC6DUt027233
	for dal-outgoing; Sat, 27 Sep 2003 14:06:13 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h8RC5doB027103;
	Sat, 27 Sep 2003 14:05:39 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h8RC5dV10031;
	Sat, 27 Sep 2003 14:05:39 +0200 (MEST)
Received: from gannet.scg.man.ac.uk(130.88.94.110) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAX6a4Ft; Sat, 27 Sep 03 14:05:38 +0200
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1A3Dnu-0006JZ-G4; Sat, 27 Sep 2003 13:04:02 +0100
Received: from [130.88.24.80] (helo=aten)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1A3Dnu-0002cB-00; Sat, 27 Sep 2003 13:04:02 +0100
Date: Sat, 27 Sep 2003 13:04:51 +0100 (BST)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@aten
To: dal@ivoa.net
cc: radio-vo@ivoa.net
Subject: Re: Simple Spectral Access use cases 
Message-ID: <Pine.GSO.4.53.0309271234460.5062@aten>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1A3Dnu-0006JZ-G4*QHqz1.U9u.s*
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Belated response - spectral model for interferometry data. This is an
attempt to highlight features consistent with Doug's comments below; it is
in no way a complete model for data cubes; for a more thorough
interferometry model see developments led by Peter Lamb in the radio-vo
and data model groups.

Doug Tody <dtody@nrao.edu> wrote:
>
> Radio data cubes are perhaps best dealt with as images with a spectral
> dimension, as they are currently represented.  It is clear though that
> a 1D spectrum could be extracted from a data cube (Ray was thinking of
> implementing a service to do this).  With future instruments (e.g. EVLA)
> with thousands of spectral channels this could be a powerful technique.
In our questionnair to interferometry data providers, most said that it
seemed much more promising to provide a VO interface to local tools to
extract such spectra, than to make VOs understand the many and volatile
ways of handling visibility data or even interferometry image cubes.
However, that is not in competition with Ray's suggestion for a generic
tool where cobes exist in suitable standard formats.

> Since such spectra can be generated on the fly most of the pecularities
> of radio data might be hidden.  The biggest problem might be how to
> characterize the observable.  Are there any other things to worry about
> that you can think of?
>
> That is, if a simple 1D spectral model includes
>
>     wavelength|frequency|energy
>     flux (observable - need to characterize, eg continuum subtracted etc.)
>     error
>
> what else is needed to describe cm or mm radio data?  Thanks.

Taking as read the information already in RSMv0.8 - other/expansion:
(much of this is in the STC models but maybe not all)

At some stage it is vital to know the velocity convention accurately - an
alarming number of astronomers don't bother to worry about this until they
do what I did and get a lovely continuum observation instead of a line.
+ Vlsr v. Vhelio, need to know date obs and what sort of Vlsr for full
  accuracy.  Nice ?Starlink? program called 'rv' supplies conversions in
  given celestial directions.
+ Vradio v. Vopt v. Vrel.
http://wiki.astrogrid.org/bin/view/Astrogrid/AstronomicalFrequency
is an attempt at a jargon buster with links to rigorous definitions

Interferometer data can have a position accuracy of mas but much older
maser data may not have been phase-referenced ie poor absolute position
accuracy, confounded by the fact that may sources have significant proper
motions so you can't just re-measure the position.

Masers can be very temporally variable and move about in the spectrum
(i.e. epoch is important; many published atlases give a list of
'peak' and 'full extent' but these may change dramatically so cannot
always be used as identifying characteristics.)

Aperture size, e.g. the resolution of a single dish or the beam size of an
interferometer for data in Jy/beam, or the region over which the flux
density was measured for information extracted from a datacube. Also
spatial filtering, see response to questionnaire below.

Polarisation - much maser data are highly polarised, typified by Zeeman
splitting (also other species, e.g. JCMT obs. of CO polarisation).  Hence
spectra/data cubes are often available in any or all of
circular correlations LL RR LR RL (or RR LL RL LR - a source of
confusion...) or the analogous
linear XX YY XY YX etc.
or the Stokes parameters  IQUV
It would be straightforward I think to translate Zeeman splitting LL-RR
into line of sight magnetic field but the user would have to convince
themselves the Zeeman pair was valid...

Single dish often published in Tant as flux units, conversion at least
approx. is possible but not always given in the same paper (cf Mag to
Jy...).

Alternatively maser data may be published as brightness temperatures -
Orion KL recently reached 10^17 K at 22 GHz for a water maser flare!

Multiple lines which may overlap e.g. OH 1665/1667 MHz; a much bigger
issue at mm freqs.  Hence there may not be a linear conversion from a
calibrated but unanalysed spectrum, to velocities - you need to assign the
lines first.

I hope the ISO people have described the use of templates, this becomes
more and more important as you get into crowded regions.  Ultimately you
want access to chemical and atomic databases.... I see there is a talk on
this at ADASS.

Even for radio, one useful thing might be to segregate typical OH/IR
twin-peaked profiles, from the narrower but less regular profiles typical
of star-forming regions (and some thinner-shelled Miras etc...)

Interpretation of HI absorption may require access to accompanying
continuum images to distinguish between absence of HI and mere absence of
background.

---------------------------
Simple Spectral Access Use Cases

Data Providers (e.g., data centers, archives)

    - Data provider name
MERLIN/VLBI National Facility, Jodrell Bank Observatory, University of
Manchester

    - Spectral data collections from this source
Spectra and SEDs in 1 2 or 3D at radio frequencies

    - Characteristics of data (number of spectra, size, irregularly
sampled, nonsampled (as in HE/UV) multiple flux arrays, variance arrays,
etc.)

MERLIN data are taken in discrete frequency bands, within which the
frequency channels are uniformly sampled.  At present the processed data
is all bandpass-corrected.  Access to the bandpass (sensitivity per
channel) is rarely needed apart from reprocessing visibility data or
planning observations but it could be supplied as look-up tables.

MERLIN has a bandwidth of 16 MHz max (until 2005 when e-MERLIN gives us 2
GHz) or less for narrow channels, a resolution of 0.5 kHz in 1.6 GHz (~100
m/s or 10^7 inverse fractional resolution) is possible but only over ~0.25
MHz - this gives a very narrow velocity coverage of tens or 100's of km/s
which may not cover all the emission from an object.

Also, some objects like nearby Mira CSEs and Galactic star-forming regions
may be poorly spatially sampled, both straightforwardly (i.e. partial
mosaics) and by the interferometric filtering of spatial frequencies.
Comparing spectra taken by e.g. VLA MERLIN VLBI gives an idea of the scale
of the emission regions but beware temporal variability.

    - Current data storage format
Processed visibility data FITS in AIPS (on line but not yet public
interface)
Images FITS on-line, published
High-res spectral raw data proprietary format on-line, will be converted
to AIPS FITS probably in medium term.

    - Is the data available online?

Present situation covering the above Q's:

MERLIN continuum and some HI data are stored on disc as processed,
calibrated visibilities.  The observatory log and FITS images are
published via CDS and are coming into the AstroGrid prototype. At present
a user would need to download images or request and download uv data in
order to extract spectra, SEDs and spectral index plots. In the near
future we hope to impliment an interface to AIPS to allow automatic
extraction of SEDs in 1 2 or 3 D. These would be returned as ascii tables
(VOTable should be OK) or FITS images as appropriate.

The data needed to make high (spectral) resolution datacubes are stored as
raw visibilities, and in the near future all we can do is tell people what
is available after a certain amount of off-line work.  However quite a lot
of these data have been analysed and published including lists of maser
components which are used to generate ID spectra at multiple spatial and
spectral locations.  One thing I would like to investigate is linking from
the observatory log to published data from journals.  This is best done
via Vizier in most cases, which means encouraging and expanding the degree
to which journals publish tables directly in Vizier or possibly provide
links.

We also host the HIJASS survey which, along with HIPASS, is the whole of
the sky in single dish mosaics in HI. It is possible to extract spectra
http://www.atnf.csiro.au/research/multibeam/release/
- David Barnes is the person to ask for details.

As part of my VO radio responsibilities I am investigating how to get a
number of other radio archives published, including single dish spectra
such as from the Puschino observatory.  The EVN VLBI online archive at
present is a list of observed positions and calibration information; a few
spectra are available but mostly for diagnostic purposes rather than
astrophysical analysis links to published data should be considered.

    - Other comments

Data Consumers (e.g., analysis packages, e.g., VO demonstrations that
might want to add the ability to fetch and display a spectrum)

    - Name of application, package, demo, etc.
Interface to AIPS/AIPS++ (managed by data providers!) to extract spectra
from interferometry and multi-beam-mosaiced data

    - Summarize capabilities of software
Specialised to handle this type of data (can handle other data with
limitiations); in particular, extracting images or direct info (incl.
spectra) from visibility data;
making spectral index maps;
measuring flux in apertures/per source intelligently to generate data for
SED or high-res spectra;
continuum subtraction from images, data cubes or (sometimes) uv data;
handles polarisation;
understands/converts velocity conventions, Jy/beam v. Jy/pixel etc,
precesses/corrects positions with required high accuracy
should propagate errors correctly.

I believe that primary beam corrections etc. can also be applied to
correct flux measurements.

    - Desired characteristics of input data
Calibrated visibility data or images

    - Desired input data format or formats (e.g., graphics, FITS, XML)
FITS at present. Also ascii/VOTable for access to extracted published
spectra.

    - Other comments

Will expand on interferometry jargon if required (tried to keep this
brief)

best wishes

Anita
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).

From owner-dal@eso.org  Wed Oct  1 14:59:36 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h91CwWIY007261
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 1 Oct 2003 14:58:32 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h91CwW7C007260
	for dal-outgoing; Wed, 1 Oct 2003 14:58:32 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Date: Tue, 30 Sep 2003 16:37:31 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200309301437.QAA07101@alinda.u-strasbg.fr>
To: dal@ivoa.net
Subject: Contribution to SIA evolution
X-Antivirus: scanned by sophos at u-strasbg.fr
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

For discussion in the DAL session of the next Interoperabilty
meeting in Strasbourg 
a contribution by F.Bonnarel, CDS and AVO (2003/09/30).

This document intends to show that a couple of limitations we encounter
using SIAP for description of heterogeneous set of data could be easilly
overcome by slight modifications in the protocol for example in version 1.1
We will first describe 2 cases of heterogeneous data, then see how we can 
express this in SIAP1.0. We'll then observe some limitations on that and try 
to find some solutions by minimal modifications to SIAP

   1 Two exemples of heterogeneous data sets 

   a example in Aladin
      As a first example just have a look of the kind of data the Aladin 
server can provide around the position of bright stars 72 tauri or Ups Tauri
in the Hyades Cluster
      The answer consists of 3 observations of 2MASS at different wavelengths
a POSSI E observation scanned in DSS1
three POSSII observations scanned in DSS2 at different wavelengths and
a POSSII J observation scanned with the mama facility

      What kind of outputs can we provide for these data? Currently the 2MASS
are provided as Atlas images , uncentered standalone pieces of sky
The next version of Aladin (planned for ADASS) will provide also mosaics
centered on the position of interest for that.
     The DSS2 and MAMA observations can be provided as full resolution cutouts 
of fixed dimension (a limitation which will disappear rather soon) or as 
 full Schmidt plate previews delivered in an Atlas mode.
      DSS1 observation can be provided in the same state, but in addition
we propose also an intermediate resolution level ( ~ 7 arcsec by pixel) 
which we deliver in cutout mode. We will probably never  provide interplates
mosaics in that case (because it gives bad results due to inacurate astrometry
on the edges of the  plates, and is generally not necessary because of wide
overlap between plates).

      All the DSS and MAMA observations can be delivered uncompressed 
(In FITS) or in JPEG. it is not yet the case for 2MASS data.

     Of course we would like to get information about the availibility
of these data in one single request.

   b example in Skyview
     For 72 tauri, Skyview provides the following list of observations:
ROSAT All Sky Survey Broad-Band
ROSAT PSPC Pointed Observations (2 deg field)
EGRET 100 MeV
34.5 MHz (Gauribidanur) Survey 
HEAO 1 A-2
COBE DIRBE
Digitized Sky Survey 1
ROSAT All Sky Survey (Soft)
2MASS J-Band Images
2MASS K-Band Images
Hydrogen Column Survey
SFD 100 micron
SFD Dust Map
PSPC 1.0 Deg-Inten
IRAS 60 micron
ROSAT All Sky Survey (Hard)
Bonn 1420 MHz/21 cm
408 MHz (Haslam) Survey
IRAS 12 micron
IRAS 25 micron 
IRAS 100 micron
GB6 (4850 Mhz)
NRAO VLA Sky Survey
    For all (or some) of these data Skyview is able to provide GIF and FITS
outputs, to modify the color table of the GIF file, to change the Projection,
etc ... Presently the Skyview SIAP Interface only provides the FITS/GNOMONIC
version. To be able to provide more, Skyview would have had to create
a large bunch of lines for each of these surveys.


       

   2  SIAP 1.0 outputs ans Limitations
How would appear  these data in SIAP 1.0 protocol? If we take the example of
Aladin we will first need to define an Atlas image service which will 
distribute 2MASS data as well as DSS1, DSS2 and mama plates previews.
It will provide the following kind of output:
    See Output 1 at the end of this document.


For the cutouts we will need to define another service (ie another URL) which
will provide another list of images:
    See Output 2 at the end of this document.



This approach works but it presents a couple of limitations for an 
heterogeneous service like ours. 
The first limitation is to have several URL (one for each service type) for
our service. We would prefer to keep all the different kinds of outputs 
together. 

The second limitation is that for the same observation (even the same piece
of sky in the cutout or mosaic cases) we can have a lot of outputs according
to the various options  of "processing" for a given "observation"  

The third one is that the geometry of the outputs cannot be defined without 
having  some idea of the limits and astrometry of the image. Let's look at
this point in more details.
    The Geometric parameters are:
POS, SIZE, INTERSECT,  together with The image generation parameters NAXIS,
CFRAME, EQUINOX, CRPIX, CRVAL, CDELT, ROTANG, PROJ
     We can distinguish  the effect of these parameters according to the kind
of service we are facing (Archive/Pointed Images, Cutout, and mosaic)

     For Archive/Pointed Image services, actually, the NAXIS, CFRAME, EQUINOX,*
 CRPIX, CRVAL, CDELT, ROTANG, PROJ parameters have no effect on the  output 
of these services. POS, SIZE (seen as a radius or dimensions of the ROI) and 
INTERSECT are the only efficient ones.

     For mosaic services on the other side, these parameters are in 
principal fully efficient and not limited in theory. Only practical reasons 
(network  transfer time,  computation time) can lead to upper limits on NAXIS
for example (limits defined by the server). So we can predefine the output 
image generation parameters as it is decribed in the SIAP 1.0 document.

     In the case of the cutout service , however we really need to know
geometric information on the observation before defining the image generation
parameters.  Actually the definition of the image of interest is the result of
a negociation. In that case, we would like to have an URL template 
instead of a simple URL on the Image_AccessReference field.

   3 propositions for SIAP 1.1
      We propose the following evolution 
          a Service type:
         In the Image_AccessReference field we will find an URL template
with A SERVICETYPE parameter defined as a variable in the template designated
by $SERVICETYPE  with "ImageAtlas", "Cutout", "Mosaic" as possible values.

          b Processing parameters: 
          Again for the Image_AccessReference field we should add a few 
parameters as variables in the URL template preceded by a $.
       We propose a MODE parameter with "ORIGIN" (for original  pixels), 
"RESAMP", or "MOSAIC" as possible values.
       We propose a COMPRESSION parameter with "NONE", "JPEG", "HCOMP", 
"MRCOMP" as possible values.
       We propose a RESOLUTION parameter with "FULL", "PREVIEW" and 
"INTERMEDIATE" as possible values.

     As was pointed out at the beginning, we can have different possibilities
of processing for different subset of Observations. This means we could need a 
VOTABLE RESOURCE for each combination of parameters. 
We can define a VOTABLE "PARAM" element for each servicetype or processing 
parameter and give the list of possible values of this parameter in the 
character value attribute of this element.
Another solution would be to define this parameter as a new field in the
output table. The list of possible values for an observation will be
given in the appropriate field of the corresponding record.


          c Geometry: We propose to use the SIAP 1.0 IGP as variables in the 
template URL with the same meaning.
The range of possible values has to be computed by the client according
to the astrometry of the image.

A more long-term consequence of these new definitions is to have only one
line by "Observation" in the output. This is a good first step towards
factorisation of metadata. Some of the details common to several "Observations"
such as "ObservingProgram" details could be deported to other resources and
just refered in the main "Observation" records. This paves the way 
towards a convergence between SIAP and a hierarchical organisation of
metadata such as the one we tested with the  IDHA experiment, the starting 
point of this hierarchy being an "Observation".


We present now  the kind of output we could obtain in the Aladin case with 
this modification (Output 3). Some of the proposed Modifications have been 
enhanced by ************** lines.
__________
Output 1:
__________
   <RESOURCE type="results">
      <INFO name="QUERY_STATUS" value="OK"/>
         <TABLE>
            <FIELD ID="Observation_Name" ucd="VOX:Image_Title" datatype="char"
arraysize="*" />
            <FIELD ID="Machine_Name" ucd="INST_ID" datatype="char"
arraysize="*" />
            <FIELD ID="CentralPoint_RA" ucd="POS_EQ_RA_MAIN" datatype="double" 
/>
            <FIELD ID="CentralPoint_DEC" ucd="POS_EQ_DEC_MAIN"
datatype="double"  />
            <FIELD ID="Naxes" ucd="VOX:Image_Naxes" datatype="int"  />
            <FIELD ID="Naxis" ucd="VOX:Image_Naxis" datatype="int"
arraysize="*" />
            <FIELD ID="AngularPixelSize" ucd="VOX:Image_Scale"
datatype="double" arraysize="*" unit="deg" />
            <FIELD ID="OriginalCoding" ucd="VOX:Image_Format" datatype="char"
arraysize="*" />
            <FIELD ID="Filter_Name" ucd="VOX:BandPass_ID" datatype= "char"
arraysize="*" />
            <FIELD ID="Effective_wavelength"  ucd="VOX:BandPass_RefValue"
datatype="double" unit="um" />
            <FIELD ID="Minimal_wavelength"  ucd="VOX:BandPass_LoLimit"
datatype="double" unit="um" />
            <FIELD ID="Maxima_wavelength"  ucd="VOX:BandPass_HiLimit"
datatype="double" unit="um" />
            <FIELD ID="Location"  ucd="VOX:Image_AccessReference"
datatype="char" arraysize="*" />
            <FIELD ID="PlateNumber"   datatype="char" arraysize="*" />
            <FIELD ID="ObservingProgram"   datatype="char" arraysize="*" />
            <FIELD ID="Resolution"   datatype="char" arraysize="*" />
            <FIELD ID="Cutout"   datatype="char" arraysize="*" />
            <FIELD ID="crtype" datatype="char" ucd="VOX:WCS_CoordProjection"
arraysize ="*" />
            <FIELD ID="crpix" datatype="double" ucd="VOX:WCS_CoordRefPixel"
arraysize= "*" />
           <FIELD ID="crval" datatype="double" ucd="VOX:WCS_CoordRefValue"
arraysize= "*" />
           <FIELD ID="cdval" datatype="double" ucd="VOX:WCS_CDMatrix"
arraysize="*" / >

                <TR>
                   <TD>2MASS_H_971031N_HI1180033</TD>
                   <TD>2MASS</TD> 
                   <TD>6.789987 </TD> 
                   <TD>23.325038 </TD> 
                   <TD>2</TD> 
                   <TD></TD> 
                   <TD>20.000000 20.000000</TD> 
                   <TD>image/fits</TD> 
                   <TD>H</TD> 
                   <TD></TD> 
                   <TD>1.500000</TD> 
                   <TD>1.800000</TD> 
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?out=image&position=6.789987+23.325038&survey=2MASS&color=H&mode=view]]></TD> 
                   <TD>971031N_HI1180033</TD> 
                   <TD>2MASS</TD> 
                   <TD> FULL</TD> 
                   <TD> STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR> 
                   <TD>2MASS_K_971031N_KI1180033</TD>
                   <TD>2MASS</TD> 
                   <TD>6.789987 </TD> 
                   <TD>23.325038 </TD> 
                   <TD>2</TD> 
                   <TD></TD> 
                   <TD>20.000000 20.000000</TD> 
                   <TD>image/fits</TD> 
                   <TD>K</TD> 
                   <TD></TD> 
                   <TD>2.000000</TD> 
                   <TD>2.320000</TD> 
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?out=image&position=6.789987+23.325038&survey=2MASS&color=K&mode=view]]></TD> 
                   <TD>971031N_KI1180033</TD> 
                   <TD>2MASS</TD> 
                   <TD> FULL</TD> 
                   <TD> STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR> 
                   <TD>2MASS_J_971031N_JI1180033</TD>
                   <TD>2MASS</TD> 
                   <TD>6.789987 </TD> 
                   <TD>23.325038 </TD> 
                   <TD>2</TD> 
                   <TD></TD> 
                   <TD>20.000000 20.000000</TD> 
                   <TD>image/fits</TD> 
                   <TD>J</TD> 
                   <TD></TD> 
                   <TD>1.110000</TD> 
                   <TD>1.30000</TD> 
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?out=image&position=6.789987+23.325038&survey=2MASS&color=J&mode=view]]></TD> 
                   <TD>971031N_JI1180033</TD> 
                   <TD>2MASS</TD> 
                   <TD> FULL</TD> 
                   <TD> STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS1_POSSI_358_E-PLATE</TD>
                   <TD>DSS1</TD>
		   <TD>7.18750</TD>
		   <TD>24.32944</TD>
		   <TD>2</TD>
		   <TD>875 875</TD>
		   <TD>0.007407392 0.007407392</TD>
		   <TD>image/fits</TD>
		   <TD>E</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
		  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.326940&fmt=FITS&resolution=PLATE&qual=POSSI%20E%20STScI]]></TD>
		   <TD>358</TD>
		   <TD>POSSI</TD>
		   <TD>PLATE</TD>
		   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
		   <TD>DSS1_POSSI_358_E-PLATE</TD>
		   <TD>DSS1</TD>
   		   <TD>7.18750</TD>
                   <TD>24.32944</TD>
                   <TD>2</TD>
                   <TD>875 875</TD>
                   <TD>0.007407392 0.007407392</TD>
                   <TD>image/jpeg</TD>
                   <TD>E</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.326940&fmt=JPEG&resolution=PLATE&qual=POSSI%20E%20STScI]]></TD>
                   <TD>358</TD>
                   <TD>POSSI</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_J-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>3.720833</TD>
                   <TD>20.10833</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20J%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_550_J-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>3.720833</TD>
                   <TD>20.10833</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
		   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
		  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20J%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
		   <TD>DSS2_POSSII_551_J-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>8.975000</TD>
                   <TD>20.15417</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
		   <TD>DSS2_POSSII_551_J-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>8.975000</TD>
                   <TD>20.15417</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>MAMA_POSSII_484_J-PLATE</TD>
                   <TD>MAMA</TD>
                   <TD>6.758333</TD>
                   <TD>25.110833</TD>
                   <TD>2</TD>
                   <TD>1024 1024</TD>
                   <TD>0.0059259259 0.0059259259</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20J%20MAMA]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>MAMA_POSSII_484_J-PLATE</TD>
                   <TD>MAMA</TD>
                   <TD>6.758333</TD>
                   <TD>25.110833</TD>
                   <TD>2</TD>
                   <TD>1024 1024</TD>
                   <TD>0.0059259259 0.0059259259</TD>
                   <TD>image/jpeg</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20J%20MAMA]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_484_J-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>6.741667</TD>
                   <TD>25.148889</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_484_J-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>6.741667</TD>
                   <TD>25.148889</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_F-PLATE</TD>
                   <TD>DSS2</TD><TD>3.716667</TD>
                   <TD>20.142500</TD><TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=iFITS&resolution=PLATE&qual=POSSII%20F%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_F-PLATE</TD>
                   <TD>DSS2</TD><TD>3.716667</TD>
                   <TD>20.142500</TD><TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20F%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_F-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>8.979167</TD>
                   <TD>20.149722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_551_F-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>8.979167</TD>
                   <TD>20.149722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                 <TR>
                   <TD>DSS2_POSSII_484_F-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>6.775000</TD>
                   <TD>25.17111</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_F-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>6.775000</TD>
                   <TD>25.17111</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                 <TR>
                   <TD>DSS2_POSSII_484_N-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>6.766667</TD>
                   <TD>25.153333</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>484</TD>*
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_N-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>6.766667</TD>
                   <TD>25.153333</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>484</TD>*
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_N-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>8.970833</TD>
                   <TD>20.139722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_N-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>8.970833</TD>
                   <TD>20.139722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_N-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>3.737500</TD>
                   <TD>20.14722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>N</TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=PLATE&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_N-PLATE</TD>
                   <TD>DSS2</TD>
                   <TD>3.737500</TD>
                   <TD>20.14722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=PLATE&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>PLATE</TD>
                   <TD>STANDALONE</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
             </TABLEDATA></DATA>
        </TABLE>
   </RESOURCE>

________
Output 2
________
   <RESOURCE type="results">
      <INFO name="QUERY_STATUS" value="OK"/>
         <TABLE>
            <FIELD ID="Observation_Name" ucd="VOX:Image_Title" datatype="char"
arraysize="*" />
            <FIELD ID="Machine_Name" ucd="INST_ID" datatype="char"
arraysize="*" />
            <FIELD ID="CentralPoint_RA" ucd="POS_EQ_RA_MAIN" datatype="double" 
/>
            <FIELD ID="CentralPoint_DEC" ucd="POS_EQ_DEC_MAIN"
datatype="double"  />
            <FIELD ID="Naxes" ucd="VOX:Image_Naxes" datatype="int"  />
            <FIELD ID="Naxis" ucd="VOX:Image_Naxis" datatype="int"
arraysize="*" />
            <FIELD ID="AngularPixelSize" ucd="VOX:Image_Scale"
datatype="double" arraysize="*" unit="deg" />
            <FIELD ID="OriginalCoding" ucd="VOX:Image_Format" datatype="char"
arraysize="*" />
            <FIELD ID="Filter_Name" ucd="VOX:BandPass_ID" datatype= "char"
arraysize="*" />

            <FIELD ID="Effective_wavelength"  ucd="VOX:BandPass_RefValue"
dataty
pe="double" unit="um" />
            <FIELD ID="Minimal_wavelength"  ucd="VOX:BandPass_LoLimit"
datatype=
"double" unit="um" />
            <FIELD ID="Maxima_wavelength"  ucd="VOX:BandPass_HiLimit"
datatype="
double" unit="um" />

            <FIELD ID="Location"  ucd="VOX:Image_AccessReference"
datatype="char" arraysize="*" />
            <FIELD ID="PlateNumber"   datatype="char" arraysize="*" />
            <FIELD ID="ObservingProgram"   datatype="char" arraysize="*" />
            <FIELD ID="Resolution"   datatype="char" arraysize="*" />
            <FIELD ID="Cutout"   datatype="char" arraysize="*" />
            <FIELD ID="crtype" datatype="char" ucd="VOX:WCS_CoordProjection"
arraysize ="*" />
            <FIELD ID="crpix" datatype="double" ucd="VOX:WCS_CoordRefPixel"
arraysize= "*" />
           <FIELD ID="crval" datatype="double" ucd="VOX:WCS_CoordRefValue"
arraysize= "*" />
           <FIELD ID="cdval" datatype="double" ucd="VOX:WCS_CDMatrix"
arraysize="*" / >
            <DATA>
              <TABLEDATA>
                <TR>
                   <TD>DSS1_POSSI_358_E</TD>
                   <TD>DSS1</TD>
		   <TD>7.18750</TD>
		   <TD>24.32944</TD>
		   <TD>2</TD>
		   <TD>875 875</TD>
		   <TD>0.007407392 0.007407392</TD>
		   <TD>image/fits</TD>
		   <TD>E</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
		  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSI%20E%20STScI]]></TD>
		   <TD>358</TD>
		   <TD>POSSI</TD>
		   <TD>FULL</TD>
		   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
		   <TD>DSS1_POSSI_358_E</TD>
		   <TD>DSS1</TD>
   		   <TD>7.18750</TD>
                   <TD>24.32944</TD>
                   <TD>2</TD>
                   <TD>875 875</TD>
                   <TD>0.007407392 0.007407392</TD>
                   <TD>image/jpeg</TD>
                   <TD>E</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSI%20E%20STScI]]></TD>
                   <TD>358</TD>
                   <TD>POSSI</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS1_POSSI_358_E-LOW</TD>
                   <TD>DSS1</TD>
		   <TD>7.18750</TD>
		   <TD>24.32944</TD>
		   <TD>2</TD>
		   <TD>875 875</TD>
		   <TD>0.007407392 0.007407392</TD>
		   <TD>image/fits</TD>
		   <TD>E</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
		  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=LOW&qual=POSSI%20E%20STScI]]></TD>
		   <TD>358</TD>
		   <TD>POSSI</TD>
		   <TD>LOW</TD>
		   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
		   <TD>DSS1_POSSI_358_E-LOW</TD>
		   <TD>DSS1</TD>
   		   <TD>7.18750</TD>
                   <TD>24.32944</TD>
                   <TD>2</TD>
                   <TD>875 875</TD>
                   <TD>0.007407392 0.007407392</TD>
                   <TD>image/jpeg</TD>
                   <TD>E</TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=LOW&qual=POSSI%20E%20STScI]]></TD>
                   <TD>358</TD>
                   <TD>POSSI</TD>
                   <TD>LOW</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_J</TD>
                   <TD>DSS2</TD>
                   <TD>3.720833</TD>
                   <TD>20.10833</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20J%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_550_J</TD>
                   <TD>DSS2</TD>
                   <TD>3.720833</TD>
                   <TD>20.10833</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
		   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
		  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20J%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
		   <TD>DSS2_POSSII_551_J<TD>
                   <TD>DSS2</TD>
                   <TD>8.975000</TD>
                   <TD>20.15417</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
		   <TD>DSS2_POSSII_551_J</TD>
                   <TD>DSS2</TD>
                   <TD>8.975000</TD>
                   <TD>20.15417</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>MAMA_POSSII_484_J</TD>
                   <TD>MAMA</TD>
                   <TD>6.758333</TD>
                   <TD>25.110833</TD>
                   <TD>2</TD>
                   <TD>1024 1024</TD>
                   <TD>0.0059259259 0.0059259259</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITSresolution=FULL&qual=POSSII%20J%20MAMA]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>MAMA_POSSII_484_J</TD>
                   <TD>MAMA</TD>
                   <TD>6.758333</TD>
                   <TD>25.110833</TD>
                   <TD>2</TD>
                   <TD>1024 1024</TD>
                   <TD>0.0059259259 0.0059259259</TD>
                   <TD>image/jpeg</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20J%20MAMA]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_484_J</TD>
                   <TD>DSS2</TD>
                   <TD>6.741667</TD>
                   <TD>25.148889</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_484_J</TD>
                   <TD>DSS2</TD>
                   <TD>6.741667</TD>
                   <TD>25.148889</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20J%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_F</TD>
                   <TD>DSS2</TD><TD>3.716667</TD>
                   <TD>20.142500</TD><TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=iFITS&resolution=FULL&qual=POSSII%20F%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_F</TD>
                   <TD>DSS2</TD><TD>3.716667</TD>
                   <TD>20.142500</TD><TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20F%20DSS2]]>
</TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_F</TD>
                   <TD>DSS2</TD>
                   <TD>8.979167</TD>
                   <TD>20.149722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_551_F</TD>
                   <TD>DSS2</TD>
                   <TD>8.979167</TD>
                   <TD>20.149722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                 <TR>
                   <TD>DSS2_POSSII_484_F</TD>
                   <TD>DSS2</TD>
                   <TD>6.775000</TD>
                   <TD>25.17111</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_F</TD>
                   <TD>DSS2</TD>
                   <TD>6.775000</TD>
                   <TD>25.17111</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20F%20DSS2]]></TD>
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                 <TR>
                   <TD>DSS2_POSSII_484_N</TD>
                   <TD>DSS2</TD>
                   <TD>6.766667</TD>
                   <TD>25.153333</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>484</TD>*
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_N</TD>
                   <TD>DSS2</TD>
                   <TD>6.766667</TD>
                   <TD>25.153333</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>484</TD>*
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_N</TD>
                   <TD>DSS2</TD>
                   <TD>8.970833</TD>
                   <TD>20.139722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_N</TD>
                   <TD>DSS2</TD>
                   <TD>8.970833</TD>
                   <TD>20.139722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_N</TD>
                   <TD>DSS2</TD>
                   <TD>3.737500</TD>
                   <TD>20.14722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/fits</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=FITS&resolution=FULL&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_N</TD>
                   <TD>DSS2</TD>
                   <TD>3.737500</TD>
                   <TD>20.14722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/jpeg</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/alapre.pl?-c=7.18750+24.32694&fmt=JPEG&resolution=FULL&qual=POSSII%20N%20DSS2]]></TD>
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>FULL</TD>
                   <TD>CUTOUT</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
             </TABLEDATA></DATA>
        </TABLE>
   </RESOURCE>
_______
Output 3
________
   <RESOURCE type="results">
      <INFO name="QUERY_STATUS" value="OK"/>
**************
      <PARAM ID="SERVICETYPE" datatype ="char" value="ImageAtlas"/>
      <PARAM ID="MODE" datatype ="char" value="ORIGIN "/>
      <PARAM ID="COMPRESSION" datatype ="char" value="JPEG NONE"/>
      <PARAM ID="RESOLUTION" datatype ="char" value="PREVIEW"/>
**************
         <TABLE>
            <FIELD ID="Observation_Name" ucd="VOX:Image_Title" datatype="char"
a
rraysize="*" />
            <FIELD ID="Machine_Name" ucd="INST_ID" datatype="char"
arraysize="*"
 />
            <FIELD ID="CentralPoint_RA" ucd="POS_EQ_RA_MAIN" datatype="double"
/>
            <FIELD ID="CentralPoint_DEC" ucd="POS_EQ_DEC_MAIN"
datatype="double"
  />
            <FIELD ID="Naxes" ucd="VOX:Image_Naxes" datatype="int"  />
            <FIELD ID="Naxis" ucd="VOX:Image_Naxis" datatype="int"
arraysize="*"
 />
            <FIELD ID="AngularPixelSize" ucd="VOX:Image_Scale"
datatype="double"
            <FIELD ID="Naxis" ucd="VOX:Image_Naxis" datatype="int"
arraysize="*"
 />
            <FIELD ID="AngularPixelSize" ucd="VOX:Image_Scale"
datatype="double"
 arraysize="*" unit="deg" />
            <FIELD ID="OriginalCoding" ucd="VOX:Image_Format" datatype="char"
ar
raysize="*" />
            <FIELD ID="Filter_Name" ucd="VOX:BandPass_ID" datatype= "char"
array
size="*" />

            <FIELD ID="Effective_wavelength"  ucd="VOX:BandPass_RefValue"
dataty
pe="double" unit="um" />
            <FIELD ID="Minimal_wavelength"  ucd="VOX:BandPass_LoLimit"
datatype=
"double" unit="um" />
            <FIELD ID="Maxima_wavelength"  ucd="VOX:BandPass_HiLimit"
datatype="
double" unit="um" />

            <FIELD ID="Location"  ucd="VOX:Image_AccessReference"
datatype="char
" arraysize="*" />
            <FIELD ID="PlateNumber"   datatype="char" arraysize="*" />
            <FIELD ID="ObservingProgram"   datatype="char" arraysize="*" />
            <FIELD ID="crtype" datatype="char" ucd="VOX:WCS_CoordProjection"
arraysize ="*" />
            <FIELD ID="crpix" datatype="double" ucd="VOX:WCS_CoordRefPixel"
arraysize= "*" />
           <FIELD ID="crval" datatype="double" ucd="VOX:WCS_CoordRefValue"
arraysize= "*" />
           <FIELD ID="cdval" datatype="double" ucd="VOX:WCS_CDMatrix"
arraysize="*" / >
            <DATA>
              <TABLEDATA>
                <TR>
                   <TD>2MASS_H_971031N_HI1180033</TD>
                   <TD>2MASS</TD> 
                   <TD>6.789987 </TD> 
                   <TD>23.325038 </TD> 
                   <TD>2</TD> 
                   <TD></TD> 
                   <TD>20.000000 20.000000</TD> 
**************
                   <TD>image/$COMPRESSION</TD> 
**************
                   <TD>H</TD> 
                   <TD></TD> 
                   <TD>1.500000</TD> 
                   <TD>1.800000</TD> 
**************
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=2MASS&color=H&mode=$MODE&comp=$COMPRESSION]]>
</TD>                    
**************
                   <TD>971031N_HI1180033</TD> 
                   <TD>2MASS</TD> 
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR> 
                   <TD>2MASS_K_971031N_KI1180033</TD>
                   <TD>2MASS</TD> 
                   <TD>6.789987 </TD> 
                   <TD>23.325038 </TD> 
                   <TD>2</TD> 
                   <TD></TD> 
                   <TD>20.000000 20.000000</TD> 
**************
                   <TD> image/$COMPRESSION</TD> 
**************
                   <TD>K</TD> 
                   <TD></TD> 
                   <TD>2.000000</TD> 
                   <TD>2.320000</TD> 
**************
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=2MASS&color=K&mode=$MODE&comp=$COMPRESSION]]></TD> 
**************
                   <TD>971031N_KI1180033</TD> 
                   <TD>2MASS</TD> 
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR> 
                   <TD>2MASS_J_971031N_JI1180033</TD>
                   <TD>2MASS</TD> 
                   <TD>6.789987 </TD> 
                   <TD>23.325038 </TD> 
                   <TD>2</TD> 
                   <TD></TD> 
                   <TD>20.000000 20.000000</TD> 
                   <TD> image/$COMPRESSION</TD> 
                   <TD>J</TD> 
                   <TD></TD> 
                   <TD>1.110000</TD> 
                   <TD>1.30000</TD> 
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=2MASS&color=J&mode=$MODE&comp=$COMPRESSION]]></TD> 
                   <TD>971031N_JI1180033</TD> 
                   <TD>2MASS</TD> 
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS1_POSSI_358_E</TD>
                   <TD>DSS1</TD>
		   <TD>7.18750</TD>
		   <TD>24.32944</TD>
		   <TD>2</TD>
		   <TD>875 875</TD>
		   <TD>0.007407392 0.007407392</TD>
		   <TD>image/$COMPRESSION</TD>
		   <TD>E</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSI&color=E&machine=DSS1&field=358&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
		   <TD>358</TD>
		   <TD>POSSI</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_J</TD>
                   <TD>DSS2</TD>
                   <TD>3.720833</TD>
                   <TD>20.10833</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=DSS2&field=550&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                <TR>
		   <TD>DSS2_POSSII_551_J<TD>
                   <TD>DSS2</TD>
                   <TD>8.975000</TD>
                   <TD>20.15417</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=DSS2&field=551&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>MAMA_POSSII_484_J</TD>
                   <TD>MAMA</TD>
                   <TD>6.758333</TD>
                   <TD>25.110833</TD>
                   <TD>2</TD>
                   <TD>1024 1024</TD>
                   <TD>0.0059259259 0.0059259259</TD>
                   <TD>JPEG,MRCOMP,FITS</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=MAMA&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_484_J</TD>
                   <TD>DSS2</TD>
                   <TD>6.741667</TD>
                   <TD>25.148889</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>J</TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=DSS2&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_F</TD>
                   <TD>DSS2</TD><TD>3.716667</TD>
                   <TD>20.142500</TD><TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=F&machine=DSS2&field=550&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_F</TD>
                   <TD>DSS2</TD>
                   <TD>8.979167</TD>
                   <TD>20.149722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=F&machine=DSS2&field=551&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_F</TD>
                   <TD>DSS2</TD>
                   <TD>6.775000</TD>
                   <TD>25.17111</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=F&machine=DSS2&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_N</TD>
                   <TD>DSS2</TD>
                   <TD>6.766667</TD>
                   <TD>25.153333</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=N&machine=DSS2&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>484</TD>*
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_N</TD>
                   <TD>DSS2</TD>
                   <TD>8.970833</TD>
                   <TD>20.139722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=N&machine=DSS2&field=551&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_N</TD>
                   <TD>DSS2</TD>
                   <TD>3.737500</TD>
                   <TD>20.14722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=N&machine=DSS2&field=550&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION]]></TD> 
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
             </TABLEDATA></DATA>
        </TABLE>
   </RESOURCE>
   <RESOURCE type="results">
      <INFO name="QUERY_STATUS" value="OK"/>
**************
      <PARAM ID="SERVICETYPE" datatype ="char" value="CUTOUT"/>
      <PARAM ID="MODE" datatype ="char" value="ORIGIN RESAMP MOSAIC"/>
      <PARAM ID="COMPRESSION" datatype ="char" value="JPEG NONE"/>
      <PARAM ID="RESOLUTION" datatype ="char" value="INTERMEDIATE FULL"/>
**************
         <TABLE>
            <FIELD ref="Observation_Name" />
            <FIELD ref="Machine_Name" />
            <FIELD ref="CentralPoint_RA" />
            <FIELD ref="CentralPoint_DEC" />
            <FIELD ref="Naxes" />
            <FIELD ref="Naxis" />
            <FIELD ref="AngularPixelSize" />
            <FIELD ref="OriginalCoding" />
            <FIELD ref="Filter_Name" />
            <FIELD ref="Effective_wavelength"  />
            <FIELD ref="Minimal_wavelength"  />
            <FIELD ref="Maxima_wavelength"  />
            <FIELD ref="Location"  />
            <FIELD ref="PlateNumber"   />
            <FIELD ref="ObservingProgram"   />
            <FIELD ref="crtype"/> 
            <FIELD ref="crpix"/> 
           <FIELD ref="crval"/> 
           <FIELD ref="cdval"/> 
            <DATA>
              <TABLEDATA>
                <TR>
                   <TD>DSS1_POSSI_358_E</TD>
                   <TD>DSS1</TD>
		   <TD>7.18750</TD>
		   <TD>24.32944</TD>
		   <TD>2</TD>
		   <TD>875 875</TD>
		   <TD>0.007407392 0.007407392</TD>
**************
		   <TD>image/$COMPRESSION</TD>
**************
		   <TD>E</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
**************
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSI&color=E&machine=DSS1&field=358&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angrefpoint=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD>
**************
		   <TD>358</TD>
		   <TD>POSSI</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_J</TD>
                   <TD>DSS2</TD>
                   <TD>3.720833</TD>
                   <TD>20.10833</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=DSS2&field=550&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angrefpoint=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                <TR>
		   <TD>DSS2_POSSII_551_J<TD>
                   <TD>DSS2</TD>
                   <TD>8.975000</TD>
                   <TD>20.15417</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=DSS2&field=551&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>MAMA_POSSII_484_J</TD>
                   <TD>MAMA</TD>
                   <TD>6.758333</TD>
                   <TD>25.110833</TD>
                   <TD>2</TD>
                   <TD>1024 1024</TD>
                   <TD>0.0059259259 0.0059259259</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=MAMA&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_484_J</TD>
                   <TD>DSS2</TD>
                   <TD>6.741667</TD>
                   <TD>25.148889</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>J</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=J&machine=DSS2&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_F</TD>
                   <TD>DSS2</TD><TD>3.716667</TD>
                   <TD>20.142500</TD><TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=F&machine=DSS2&field=550&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>550</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_F</TD>
                   <TD>DSS2</TD>
                   <TD>8.979167</TD>
                   <TD>20.149722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=F&machine=DSS2&field=551&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_F</TD>
                   <TD>DSS2</TD>
                   <TD>6.775000</TD>
                   <TD>25.17111</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>F</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=F&machine=DSS2&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref

point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>484</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>
                 <TR>
                   <TD>DSS2_POSSII_484_N</TD>
                   <TD>DSS2</TD>
                   <TD>6.766667</TD>
                   <TD>25.153333</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=N&machine=DSS2&field=484&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>484</TD>*
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_551_N</TD>
                   <TD>DSS2</TD>
                   <TD>8.970833</TD>
                   <TD>20.139722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=N&machine=DSS2&field=551&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>551</TD>
                   <TD>POSSII</TD>
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                </TR>
                <TR>
                   <TD>DSS2_POSSII_550_N</TD>
                   <TD>DSS2</TD>
                   <TD>3.737500</TD>
                   <TD>20.14722</TD>
                   <TD>2</TD>
                   <TD>90 960</TD>
                   <TD>0.006666 0.0066666</TD>
                   <TD>image/$COMPRESSION</TD>
                   <TD>N</TD>
                   <TD></TD>
                   <TD></TD>
                   <TD></TD>
                  
<TD><![CDATA[http://aladin.u-strasbg.fr/cgi-bin/nph-HTTP.cgi?type=$SERVICETYPE&out=image&position=6.789987+23.325038&survey=POSSII&color=N&machine=DSS2&field=550&mode=$MODE&comp=$COMPRESSION&resolution=$RESOLUTION&angref
point=$CRVAL&pixrefpoint=$CRPIX&size=$SIZE]]></TD> 
                   <TD>550</TD> 
                   <TD>POSSII</TD> 
                   <TD>1544,1544</TD>^M
                   <TD>RA--TAN, DEC--TAN</TD>^M
                   <TD>772,772</TD>^M
                   <TD>66.8226978,22.9963367</TD>^M
                   <TD>1,1</TD>^M
                 </TR>  
             </TABLEDATA></DATA>
        </TABLE>
   </RESOURCE>



=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Thu Oct  2 13:16:30 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h92BD0jd019449
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 2 Oct 2003 13:13:00 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h92BD0RI019444
	for dal-outgoing; Thu, 2 Oct 2003 13:13:00 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h92BCOjd019212
	for <dal@ivoa.net>; Thu, 2 Oct 2003 13:12:24 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id h92BCOw02552
	for <dal@ivoa.net>; Thu, 2 Oct 2003 13:12:24 +0200 (MEST)
Message-ID: <3F7C08C3.2060100@eso.org>
Date: Thu, 02 Oct 2003 13:15:15 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Re: Contribution to SIA evolution
References: <200309301437.QAA07101@alinda.u-strasbg.fr>
In-Reply-To: <200309301437.QAA07101@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Francois,

The condensed notation based on some URI templates makes sense. For the 
implementation we might consider XPATH (http://www.w3.org/TR/xpath).

 > <TD><![CDATA[http:/...?type=$SERVICETYPE&mode=$MODE&comp=$COMPRESSION...]]></TD>

Has anybody tried to generate URIs dynamically based on the values of VOTABLE 
cells yet?

For small sets of possible parameter values one could probably use entities, 
but for other parameters with a wide range of possible values that's not 
practical. So again, XPATH is the only solution I can think of right now if we 
want to stick to some off the shelf solution.


 > c Geometry: We propose to use the SIAP 1.0 IGP as variables in the

What does IGP stand for?

Cheers,
Markus

+---
| Markus Dolensky   Mailto:Markus.Dolensky@eso.org
| AVO Technical Lead          Web: www.euro-vo.org
| Voice: ++49 89 32006/261  Fax: ++49 89 32006/480
+---

From owner-dal@eso.org  Thu Oct  2 13:45:51 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h92Bipjd028326
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 2 Oct 2003 13:44:51 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h92BipC6028324
	for dal-outgoing; Thu, 2 Oct 2003 13:44:51 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h92Bhjjd027944;
	Thu, 2 Oct 2003 13:43:46 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h92BhjM10713;
	Thu, 2 Oct 2003 13:43:45 +0200 (MEST)
Received: from ns1.u-strasbg.fr(130.79.200.1) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAAQ8a46u; Thu, 2 Oct 03 13:43:44 +0200
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9/jtpda-5.4) with ESMTP id h92Bhhdi051447
          ; Thu, 2 Oct 2003 13:43:43 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id NAA02926;
	Thu, 2 Oct 2003 13:33:54 +0200 (MET DST)
Date: Thu, 2 Oct 2003 13:33:54 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200310021133.NAA02926@alinda.u-strasbg.fr>
To: Markus.Dolensky@eso.org, dal@ivoa.net
Subject: Re: Contribution to SIA evolution
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by ns1.u-strasbg.fr id h92Bhhdi051447
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h92Bikjd028273
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi markus,
   Partial Answer: IGP is for Image Generation Parameters, as described by
SIAP 1.0 reference documentation.
Cheers
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Tue Oct  7 22:58:41 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97Kw8LU023598
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 7 Oct 2003 22:58:08 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h97Kw87m023596
	for dal-outgoing; Tue, 7 Oct 2003 22:58:08 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from eso-wall-ext.hq.eso.org (firewall-user@eso-wall-int.hq.eso.org [134.171.68.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h97KuwLU023140;
	Tue, 7 Oct 2003 22:56:58 +0200 (MEST)
Received: (from uucp@localhost)
	by eso-wall-ext.hq.eso.org (8.10.2+Sun/8.10.2) id h97KuwT02698;
	Tue, 7 Oct 2003 22:56:58 +0200 (MEST)
Received: from revere.aoc.nrao.edu(146.88.1.15) by eso-wall-ext.hq.eso.org via csmap (V6.0)
	id srcAAATzairf; Tue, 7 Oct 03 22:56:57 +0200
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id h97KuoE32722;
	Tue, 7 Oct 2003 14:56:50 -0600
Received: from oak (oak [146.88.1.137])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id h97Kuh72024980;
	Tue, 7 Oct 2003 14:56:43 -0600 (MDT)
Date: Tue, 7 Oct 2003 14:56:43 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: "Wil O'Mullane" <womullan@skysrv.pha.jhu.edu>
cc: "'voql'" <voql@ivoa.net>, <dal@ivoa.net>
Subject: Re: A Working document has been submitted
In-Reply-To: <20031007140427.E28585@skysrv.pha.jhu.edu>
Message-ID: <Pine.LNX.4.44.0310071432590.11291-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.2, required 7,
	EMAIL_ATTRIBUTION, IN_REP_TO, SPAM_PHRASE_00_01, USER_AGENT_PINE)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

We had a similar discussion in the context of DAL a while back, and ended
up proposing a new tag UTYPE for this purpose.  UTYPE is a pointer into
a data model, and serves to identify the unique data model attribute
associated with, e.g, a field or column of a VOTable (and also thereby
indirectly associating all the attributes of a given data model).
The same field could also have a UCD, which serves a different purpose.

The idea goes like this:

    o	We formally define a data model somewhere on the Web within the VO.
    	This includes a namespace for each data model (and other things
	such as a schema, whitepaper defining the data model, etc.).

    o	A VOTable which uses a given data model (DM) will reference the DM
	namespace.

    o	Each UTYPE tag specifies the data model namespace, and the data
    	model attribute associated with the field or other data item,
	e.g., UTYPE=<dm><attribute>.

    o	The attributes of a data model can thus be mapped into votable
    	columns (or other structures), with the ability to rigorously
	identify and associate each such DM attribute.  One can then do
	things like extract the DM attributes and pass them off to 
	analysis software, go back to the published DM schema to autoverify
	the DM attributes, and so forth.

Both UCD (fuzzy knowledge tags) and UTYPE (rigorous pointer into data
model) have their place.  UCD provides a simple way to do semantic
associations without requiring data models, topic maps, etc., and UTYPE
allows one to reliably use data models, e.g., for data analysis or for
more precise queries.

	- Doug


On Tue, 7 Oct 2003, Wil O'Mullane wrote:

> I would rather hope we map not to UCD but to Data Model terms.
> We were rather thinking of this mapping being at perhaps a higherlevel
> so skynode would just respond to its own schema but some other portal 
> would take a query interms of UCDS and rewrite it using appropriate colum
> names. Another portal might do the same for Data Model terms etc..
> So Althoutgh I thinkthe SkyNode must publish its ucds I think any query
> comming in should be in terms of the proper column names..
> 
> > 
> > > I think it is essential that ADQL support theuse of *both* UCDs and column
> > > names. It'll be up to the query interface to substitute column names (by
> > > asking the user probably) where UCDs are not uniquely resolvable.
> > > 
> > > Cheers,
> > > Tony. 
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: owner-voql@eso.org [mailto:owner-voql@eso.org] On 
> > >>Behalf Of Roy Williams
> > >>Sent: 07 October 2003 15:50
> > >>To: Clive Page; voql
> > >>Subject: Re: A Working document has been submitted
> > >>
> > >>
> > >>
> > >>>  Region ('CIRCLE J2000 19.5 -36.7 0.02')
> > >>
> > >>I have a question in the same style. I would like to start 
> > >>using the UCD ontology within VOQL. I am imagining metadata 
> > >>queries like
> > >>
> > >>select table where UCDMatch(table, "phys.velocity, src.galaxy") > 0.8
> > >>
> > >>in order to find tables that have galactic velocities. Can 
> > >>VOQL be extended in this way?
> > >>
> > >>Roy
> > >>
> > > 
> > > 
> > 
> 
> 

From owner-dal@eso.org  Fri Oct 17 17:28:39 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9HFQswb026923
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 17 Oct 2003 17:26:54 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9HFQsuI026922
	for dal-outgoing; Fri, 17 Oct 2003 17:26:54 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9HFQHwb026726
	for <dal@ivoa.net>; Fri, 17 Oct 2003 17:26:17 +0200 (MEST)
Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9HFQGB1026951
	for <dal@ivoa.net>; Fri, 17 Oct 2003 17:26:17 +0200 (CEST)
Received: from nmail1.systems.pipex.net (localhost [127.0.0.1])
	by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id h9HFQGm7002526
	for <dal@ivoa.net>; Fri, 17 Oct 2003 16:26:16 +0100
Received: (from nobody@localhost)
	by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id h9HFQGdv002525
	for dal@ivoa.net; Fri, 17 Oct 2003 16:26:16 +0100
Received: from 80.14.69.222 ( [80.14.69.222])
	as user abm36@dial.pipex.com by netmail.pipex.net with HTTP;
	Fri, 17 Oct 2003 16:26:16 +0100
Message-ID: <1066404376.3f900a183f648@netmail.pipex.net>
Date: Fri, 17 Oct 2003 16:26:16 +0100
From: martin hill <mchill@dial.pipex.com>
To: dal@ivoa.net
Subject: FORTRAN access to .NET web services
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PIPEX NetMail (IMP3.1)
X-Originating-IP: 80.14.69.222
X-PIPEX-Username: abm36%dial.pipex.com
X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: martin hill <mchill@dial.pipex.com>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

http://www.lahey.com/lf70/netwtpr1.htm#web

should work with other WSDL-defined web services too.  

We had a discussion about providing document-based web services vs RPC web 
services on the AstroGrid project, at

http://forum.astrogrid.org/read.php?action=lastpost&TID=452

We originally provided document-based web-service datacenters and they 
worked.  We are now going to transfer over to RPC ones and either I shall 
say "I told you so" or say nothing at all and pretend I approved.

I would be interested to know how the folks on this list feel about creating 
various web services.  I get the impression that people are happy creating 
http/get-based ones (like the NVO cone search is, and the SIAP and SSA will 
be) but feel a bit more wary of document-based ones (whether http/get-serviced 
or Remote-Procedure-Call serviced) and very sceptical about fully RPC-ones. 
Yet I am told that in fact making WSDL-described RPC services is as easy or 
easier than http/get based ones. This was by software engineers though; I 
expect to get to grips with both over the next few weeks, and if people are 
interested I will report back to this group (and DAL) about how easy it 
was/wasnot.
  

-- 
Martin Hill
07901 55 24 66
www.mchill.net

From owner-dal@eso.org  Fri Oct 17 18:31:09 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9HGU8wb014041
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 17 Oct 2003 18:30:08 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9HGU8bh014037
	for dal-outgoing; Fri, 17 Oct 2003 18:30:08 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9HGTWwb013830
	for <dal@ivoa.net>; Fri, 17 Oct 2003 18:29:32 +0200 (MEST)
Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9HGTWs3010411
	for <dal@ivoa.net>; Fri, 17 Oct 2003 18:29:32 +0200 (CEST)
Received: from nmail1.systems.pipex.net (localhost [127.0.0.1])
	by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id h9HGTVm7005872
	for <dal@ivoa.net>; Fri, 17 Oct 2003 17:29:31 +0100
Received: (from nobody@localhost)
	by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id h9HGTV8E005871
	for dal@ivoa.net; Fri, 17 Oct 2003 17:29:31 +0100
Received: from 81.48.244.212 ( [81.48.244.212])
	as user abm36@dial.pipex.com by netmail.pipex.net with HTTP;
	Fri, 17 Oct 2003 17:29:31 +0100
Message-ID: <1066408171.3f9018eb50d37@netmail.pipex.net>
Date: Fri, 17 Oct 2003 17:29:31 +0100
From: martin hill <mchill@dial.pipex.com>
To: dal@ivoa.net
Subject: Data service types
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PIPEX NetMail (IMP3.1)
X-Originating-IP: 81.48.244.212
X-PIPEX-Username: abm36%dial.pipex.com
X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: martin hill <mchill@dial.pipex.com>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi all

One thing that didn't seem very clear from the meetings was what DAL was all 
about.  We talked about the technicalities of two particular services: Images 
and Spectra, but the rather larger set including stellar catalogues and other 
databases of information wasn't considered (as if we didn't have enough to 
talk about!).

Are we assuming just now that we are working on three services: images (SIAP 
as cutout and 'as-stored'), spectra (SSA in early stages) and stellar 
catalogues (as SkyNode2, being defined)?  As an Astrogrid datacenter developer 
I need to know who I should be talking to about making sure things are 
compatible! Will & I have already been talking, but if the group feels that 
SkyNode2 will be the *defining* interface for ADQL-querying VO datacenters, 
and NVO Cone Searches for http/get VO datacenters, then we shall happily work 
towards that (and provide input to that!).  If not we need to know!  We have 
now 3 astrogrid datacenters running in various versions, and by Christmas 
expect to have around 6-10 homogenous, so we need to know...! 

Also a suggestion that I think came up somewhere in the meeting, that we make 
the formats of the http/get urls similar.  This (might?) save having to use 
template urls (if that's what was meant by them).  For example, at the moment 
the SIAP uses a comma to separate RA/DEC, whereas NVO cone search specifies 
them explicitly.

Finally (really) I would also like to find out here what services people want 
to publish to the VO and some idea of the structure of that data, so we can 
build an overall picture of what the VO is likely to be serving. 

Cheers,

Martin

-- 
Martin Hill
07901 55 24 66
www.mchill.net

From owner-dal@eso.org  Mon Oct 20 20:44:17 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9KIdJMY021729
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 20 Oct 2003 20:39:19 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9KIdJvq021728
	for dal-outgoing; Mon, 20 Oct 2003 20:39:19 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9KIcjMY021494
	for <dal@ivoa.net>; Mon, 20 Oct 2003 20:38:45 +0200 (MEST)
Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9KIcjs3012542
	for <dal@ivoa.net>; Mon, 20 Oct 2003 20:38:45 +0200 (CEST)
Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk ident=root)
	by mercury.ex.ac.uk with esmtp (Exim 4.14)
	id 1ABevV-00QVqS-4e; Mon, 20 Oct 2003 19:38:45 +0100
Received: from localhost by dastardly.astro.ex.ac.uk; Mon, 20 Oct 2003 19:38:44 +0100
Date: Mon, 20 Oct 2003 19:38:44 +0100 (BST)
From: Alasdair Allan <aa@astro.ex.ac.uk>
To: martin hill <mchill@dial.pipex.com>
cc: dal@ivoa.net
Subject: Re: FORTRAN access to .NET web services
In-Reply-To: <1066404376.3f900a183f648@netmail.pipex.net>
Message-ID: <Pine.LNX.4.44.0310201936330.5182-100000@dastardly.astro.ex.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alasdair Allan <aa@astro.ex.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


> We had a discussion about providing document-based web services vs RPC web 
> services on the AstroGrid project, at
> 
> http://forum.astrogrid.org/read.php?action=lastpost&TID=452
> 
> We originally provided document-based web-service datacenters and they 
> worked.  We are now going to transfer over to RPC ones and either I shall 
> say "I told you so" or say nothing at all and pretend I approved.

I thought that most people had agreed that sending a document, but over 
RPC, was probably the best way to go? 

In other words, we're not taking abotu document literal services, but an
XML document sent as a "string" via an RPC service... or have I totally
misunderstood?
 
Al.
-- 
Dr. A. Allan, School of Physics, University of Exeter

From owner-dal@eso.org  Tue Oct 21 00:12:46 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9KM7pPG010748
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 21 Oct 2003 00:07:51 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9KM7p1K010747
	for dal-outgoing; Tue, 21 Oct 2003 00:07:51 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9KM7IPG010599
	for <dal@ivoa.net>; Tue, 21 Oct 2003 00:07:18 +0200 (MEST)
Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9KM7Hs3017375
	for <dal@ivoa.net>; Tue, 21 Oct 2003 00:07:18 +0200 (CEST)
Received: from nmail1.systems.pipex.net (localhost [127.0.0.1])
	by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id h9KM6km7008151;
	Mon, 20 Oct 2003 23:06:47 +0100
Received: (from nobody@localhost)
	by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id h9KM6k3H008150;
	Mon, 20 Oct 2003 23:06:46 +0100
Received: from 81.86.226.147 ( [81.86.226.147])
	as user abm36@dial.pipex.com by netmail.pipex.net with HTTP;
	Mon, 20 Oct 2003 23:06:46 +0100
Message-ID: <1066687606.3f945c764bb86@netmail.pipex.net>
Date: Mon, 20 Oct 2003 23:06:46 +0100
From: martin hill <mchill@dial.pipex.com>
To: Alasdair Allan <aa@astro.ex.ac.uk>
Cc: dal@ivoa.net
Subject: Re: FORTRAN access to .NET web services
References: <Pine.LNX.4.44.0310201936330.5182-100000@dastardly.astro.ex.ac.uk>
In-Reply-To: <Pine.LNX.4.44.0310201936330.5182-100000@dastardly.astro.ex.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PIPEX NetMail (IMP3.1)
X-Originating-IP: 81.86.226.147
X-PIPEX-Username: abm36%dial.pipex.com
X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: martin hill <mchill@dial.pipex.com>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Oh. Ah.  etc.  I thought we'd agreed that any service would *as a minimum* offer
document-based interfaces, but I thought this was in the http/get/post interface
body....

Who (if anyone) was taking the minutes? 

Quoting Alasdair Allan <aa@astro.ex.ac.uk>:

> 
> > We had a discussion about providing document-based web services vs RPC web
> 
> > services on the AstroGrid project, at
> > 
> > http://forum.astrogrid.org/read.php?action=lastpost&TID=452
> > 
> > We originally provided document-based web-service datacenters and they 
> > worked.  We are now going to transfer over to RPC ones and either I shall 
> > say "I told you so" or say nothing at all and pretend I approved.
> 
> I thought that most people had agreed that sending a document, but over 
> RPC, was probably the best way to go? 
> 
> In other words, we're not taking abotu document literal services, but an
> XML document sent as a "string" via an RPC service... or have I totally
> misunderstood?
>  
> Al.
> -- 
> Dr. A. Allan, School of Physics, University of Exeter
> 
> 


-- 
Martin Hill
07901 55 24 66
www.mchill.net

From owner-dal@eso.org  Tue Oct 21 21:33:59 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9LJU4d5016385
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 21 Oct 2003 21:30:04 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9LJU483016384
	for dal-outgoing; Tue, 21 Oct 2003 21:30:04 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9LJSUd5015689;
	Tue, 21 Oct 2003 21:28:31 +0200 (MEST)
Received: from milkyway.gsfc.nasa.gov (lheapop.gsfc.nasa.gov [128.183.16.62])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9LJSSs3010478;
	Tue, 21 Oct 2003 21:28:29 +0200 (CEST)
Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68])
	by milkyway.gsfc.nasa.gov (8.12.9/8.12.9) with ESMTP id h9LJSRTd020928;
	Tue, 21 Oct 2003 15:28:27 -0400
Message-ID: <3F9588DF.3030805@lheapop.gsfc.nasa.gov>
Date: Tue, 21 Oct 2003 15:28:31 -0400
From: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ucd@ivoa.net, dm@ivoa.net, dal@ivoa.net
Subject: A suggested revision for UCDs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


A few minutes ago I uploaded a version of my suggested revised
proposal for UCDs to the Twiki.  This is just a Word version since
I don't have a PDF generator handy.  The URL is
    http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-1.9.9b.doc

This builds upon Roy and Sebastien's division of UCDs into concepts
and propeties but puts them together rather differently.

In addition and largely independently, it includes a discussion
of the use of UCDs in the context of groups of columns and
tables as a whole.  With the approach suggested, I hope that the
ambiguities that have heretofore precluded considering using UCDs
to mediate between data models and data can be removed and we may
no longer require a utype parameter.

Some discussion of the document is included (in red) within the
text.  This mostly describes the relationship of this version to
the 1.9.9 version.

Sections 3 and 6 of the document are copied from the previous version.
(though section 6 was section 8 in that document) from the
previous version.  The abstract is altered to reflect the discussion
of grouping constructs.  Section 2 -- describing the status of the document --
has been changed to discuss the implications of the adoption of this
recommendation upon existing software systems and protocols.  I think
that some such statement should be part of draft recommendations.  Not sure if
that's part of the recommendation process but it probably should be.

Section 4 is the discussion of UCDs and UCD syntax.  At the end of section 4 there
is a long parenthetical discussion of some of the ways this proposal differs from 1.9.9
since people seemed to be concerned about that last Thursday.  If they've
gotten this far they probably don't need this anymore but it may be of interest.
This section tries to be rather rigorous -- addressing a fair number of nits that
had not been talked about in the earlier proposal even though it makes
the proposal somewhat longer (e.g., the discussion of array valued cells,
a much more detailed discussion of comparability of columns, how to ensure the
uniqueness of UCDs, ...)

The actual definition of all of the valid words for UCDs is deferred
as it was in the earlier version, but a substantial number of examples are given.
[In fact, most of the words should transfer between the two versions fairly
transparently.  The differences lie mostly in how they are put together.]

Section 5 is the dicussion of UCDs and grouping structures.  I'm quite
excited by this since I think it real potential for helping to unify discussions
of data, data models and data access.  The discussion
in this chapter is less rigorous -- even if the basic idea is adopted I'm sure
it will need substantially more work but I think it has real possibilities for
linking data models and data.  This chapter is why I've sent this message
to the DAL and DM groups as well as to the UCD group.  Apologies to all of
you who get this twice or thrice!

I trust there will be comments...


	Tom


From owner-ucd@eso.org  Tue Oct 21 21:56:40 2003
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9LJqOd5024031
	for <ucd-outgoing@mercury.hq.eso.org>; Tue, 21 Oct 2003 21:52:24 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9LJqO0i024030
	for ucd-outgoing; Tue, 21 Oct 2003 21:52:24 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9LJpHd5023794;
	Tue, 21 Oct 2003 21:51:17 +0200 (MEST)
Received: from milkyway.gsfc.nasa.gov (lheapop.gsfc.nasa.gov [128.183.16.62])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9LJpEs3010970;
	Tue, 21 Oct 2003 21:51:15 +0200 (CEST)
Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68])
	by milkyway.gsfc.nasa.gov (8.12.9/8.12.9) with ESMTP id h9LJpETd022259;
	Tue, 21 Oct 2003 15:51:14 -0400
Message-ID: <3F958E35.1090703@lheapop.gsfc.nasa.gov>
Date: Tue, 21 Oct 2003 15:51:17 -0400
From: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dal@ivoa.net, ucd@ivoa.net
Subject: Re: UCD use cases
References: <Pine.GSO.4.44L0.0310211239510.21915-100000@sparky.star.le.ac.uk> <049b01c397e1$57b39ad0$6501a8c0@Ropy>
In-Reply-To: <049b01c397e1$57b39ad0$6501a8c0@Ropy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Here are some thoughts about how the new UCD scheme I've
proposed might help in Roy's scenarios.  I'd sent
this to Roy directly earlier without realizing
that it had been sent to the UCD and DM groups....

	Tom


> 
> (1) Cone search. How to decide which columns are the RA,Dec that was used in
> the search. What frame (B1950, J2000, ...) do these come from? If there are
> columns with ID, what sort of ID is it, and how do I resolve it?
> 


UCDtrees look something like:
     src;instance
         meta.id[.type];value
	pos;instance
             ra/dec, l/b columns
	    pos.coosys;value   Optional, either table coosys element
                                of the table or a table wide parameter

Look for highest pos;instance and meta.id;value to get the correct id and pos columns.
If we want to handle B1950 coordinates then we need to include a table parameter
or parameters including the coordinate system.  Of course the cone search protocol
requires that the output be in J2000, but it would be easy to support genericity
if we want.  I suggested that the coosys element in tables could have a UCD, but
less controversial would be a table parameter giving the information.  That's not
quite as elegant.  However I don't like duplicating metadata information.  Maybe
the best solution is to include a parameter but make it point to the coosys using
the XML ID.

Not sure what you mean by resolve the id, but assuming that this isn't addressed
by specific subtypes of id, replace meta.id;value with

        meta.id;instance
	     meta.id;value
	     meta.id.resolver;value

meta.resolver;value would presumably be a parameter but in principal if there
was a different resolver for each row in the table it could be a column.



> (2) SIAP search. Find the column that contains the URLs where the images
> are. Find out if there are other columns that have RA,Dec of the image
> center.

Basic UCDTree is:

       obs;instance
	   meta.id;value	# The required id field
	   meta.link;value      # The link field
	   pos;instance	        # The required position

These are mandated columns in the SIAP protocol and the protocol should
also specify that there is only one pos, meta.id and meta.link element
at the top level.  Note, by the by, that if we want to allow the SIAP protocol
to return galactic positions, it's easy to do.  [This isn't necessarily a
good idea for SIAP, but the it shows the expressivity of the UCDTrees.]

Could there be an image center that is distinct from this image?  This would
require there to be an associated observation to the main observation.
[If I really want to go overboard I might have made the table UCD
        obs;filter.cutout;instance
but I don't think that that is going to be useful to most people,
though it does show a nice use of my suggested filter hierarchy.]

This could be suggested by adding the following to the tree
            obs;instance
                 meta.id;value
                 pos;instance

The issue which is harder to address is understanding the relationship between
this secondary observation and the primary observation.  This is a semantic issue
not a structural one, so a UCD must be involved.  E.g., we need to define
concepts for background, center, offset, ...  If we have done that (and I would
suggest they belong in my meas tree since they have to do with idea of a measurement)
then the previous addendum becomes [and I've put in a background image for good measure]
	   obs.instance
		meta.id;value
                 obs;meas.center
			pos;instance
	   obs.instance
		meta.id;value
		obs;meas.background
			pos;instance


How do I find this...  I look for associated observations and search for
one which has the desired measurement attribute.  I believe an XQuery expression
can do this pretty easily.

> 
> (3) We have for example a crossmatch service that is clever enough to know
> about error ellipses. How does it get from a table the most sophisticated
> error info that is there: (a) position (b) circular error (c) ellipse error.

This is pretty easy...
Looking just at a given position, we might have:

      pos;instance
	pos.eq.ra;value
	pos.eq.dec;value
	pos.eq.ra;meas.error         Errors in the coordinates
	pos.eq.ra;meas.error
	pos;meas.2d.error            This is a circular 2-d error
	pos;meas.2d.error.elliptical;instance
              pos;meas.2d.error.elliptical.x
              pos;meas.2d.error.elliptical.y
              pos;meas.2d.error.elliptical.posang
	

which gives all three of these.  While there may be
a better name for the last two errors, I don't think it matters
much.  Whatever error there is is directly associated with the position
and it's easy to find out what errors are availalbe.  The question
of which error the user should use, is not appropriate for
the UCD scheme.  That's up to the user.  The UCDs indicate
which errors are available.

I'm not sure if we want to elaborate the measurement tree
to this level, maybe it could be done more simply in some other way.
However I don't think this is an unreasonable approach.

> 
> (4) We want to compare photometry in two tables covering the same star
> cluster. How do I decide if they share measurements in the same filter? One
> has R band, the other has Halpha. What happens if fluxes are expressed
> differently -- eg number / energy /
> magnitude / luminosity density.

Well I don't think unit conversions are an issue that UCDs should address.
So I'll pass on that.  [That's what units keywords are for after all.]

The columns should describe the bands in which they were taken.  If
we want to assure that we actually have the same filter, then we
need UCDs that are specific down to the filter level.  The old UCD tree
(and I assume you've kept it in the current one) puts all of that info
in the initial word.  I'd tend to use the em modifier here to define
the band.   E.g.,

      phot.mag;em.optical.filter.v.johnson;value
      phot.flux;em.optical.filter.v.johnson;value
and
      phot.counts;em.optical.filter.v.johnson;value
for magnitude, flux and counts (in a photon counting instrument)

If the question is whether the filters overlap, then I don't think
this is a question the UCDs answer directly.  It's expert knowledge
about the concepts (Just like the exact relationship between RA and Dec
isn't specified in the UCD.  That's expert knowledge too.)


> (5) I want distances to stellar objects measured in meters, so I can make a
> 3D display for the children. How do I recognize a redshift (z) value, how do
> I recognize a radial velocity, how do I recognize an actual distance
> measure?


Units are not a UCD issue.
The other questions simply need distinct UCDs.  As I understand the schema they
would just be different elements of the phys tree but that's a bit of a guess.
Redshift is a different concept from distance as is a radial velocity.  They can
be converted into each other in certain circumstances, but it is not the role
of UCDs to understand the transformation rules -- just as it is not the role
of UCDs to understand how to convert from RA,Dec to L,B.  I think it may be reasonable
to have all of the base concepts:

      	phys.distance		A distance of some kind
   	phys.distance.z		A redshift in a cosmological context
	phys.distance.vrad	A radial velocity in a cosmological context
	phys.z			A redshift in non-cosmological context
	phys.vrad		A radial

or to only have the single distance concept and leave it to the user to recognize
that they are in a cosmological context so that radial velocities can be converted
to distances.  That's probably safer from the context
of trying to ensure that there is only one UCD for a given concept so I'd
tend to go that way.  Users put z in a table rather than distance for a reason.

UCDs describe what a column is, they need not and should not describe what you
can do with a column.  I gather that is the role of ontologies.

> 
> (6) I am looking for supernovae that have both optical and Xray
> measurements. Can I (should I) use UCD to help my search?

You can certainly try.  This depends a bit upon the specific UCD tree.
If table UCDs are often of the form
     src.[type];instance
you can search the registry for tables of the form
     src.supernova;instance

Similarly ou can use search columns the phot and look for
optical and X-ray qualifiers.  If you get tables that meet all the
criteria you've got a great place to start.   I.e., look for UCDTree
that matches the template

    src.supernovae;instance
    //phot*;em.xray*;value
    //phot*;em.optical*;value

[Where this is some Xqueryish kind of match to the UCDTree hierarchy]

and you've got a great chance that this has the information you wnat.

Even if there is no match, you can consider tables that are partial
hits and look to see if you can join information appropriately using
multiple tables.

A real win here  would be a VO service to enable comparison of class
information among tables.  Right
now source classes are a real mess and we need a Simbad- or NED-like service to address
it. That will probably be needed if you want to interrogate the vast
majority of UCDTrees that with have src;instance and some classification
parameter inside.

> 
> (7) How do I find 21cm observations (that may be redshifted), which also
> have polarization information?
> 
> 

Look for all tables that have columns that match
     flux.phot*;em.pol*;value
to get polarization information

Limit to tables that have a flux value in the 21cm region
-- don't know if that has it's own special UCD -- or which has
flux in the region from 10-100 cm and a redshift or radial velocity.
This assumes there is some service that gives me the em qualifiers
I need to look for given a specific energy/wavelength/frequency range.
It wouldn't be too hard by hand either.

This is a straightforward analysis of the column UCDs that doesn't
need to worry about the structure UCDs at all.



From owner-dal@eso.org  Wed Oct 22 19:21:20 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9MHGMKp003608
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 22 Oct 2003 19:16:22 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9MHGMIh003607
	for dal-outgoing; Wed, 22 Oct 2003 19:16:22 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9MHFmKp003459;
	Wed, 22 Oct 2003 19:15:48 +0200 (MEST)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9MHFis3004937;
	Wed, 22 Oct 2003 19:15:45 +0200 (CEST)
Received: from aria (aria.stsci.edu [130.167.236.125])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AGU13171;
	Wed, 22 Oct 2003 13:15:37 -0400 (EDT)
Message-ID: <021901c398c0$1ec33c00$7deca782@stsci.edu>
From: "Robert Hanisch" <hanisch@stsci.edu>
To: <dal@ivoa.net>, <ucd@ivoa.net>
Subject: Fw: A suggested revision for UCDs
Date: Wed, 22 Oct 2003 13:15:37 -0400
Organization: Space Telescope Science Institute
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu)
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Robert Hanisch" <hanisch@stsci.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Here is a discussion that Tom and I had off-list, but I think are number of
points of more general interest are raised.  Warning -- it is quite long!

Bob

- - - - -

Hi Bob,

Thanks for the review and comments.  I'm particularly interested
in the areas that were unclear.  It seemed to me that I needed to
actually put the ideas out where I could get some detailed reactions.
A fair number of typo issues were addressed in the version I uploaded
to the Twiki and announced to the UCD, DM and DAL groups.  Haven't
heard of any reaction.

I've responded to your comments below (there a lot of detail
but I thought it user to think these things through).

Tom

Robert Hanisch wrote:
> Hi Tom.  I read through your revised UCD document this evening.  Phew.
> There is much in it I like, much I don't, and much I don't follow.
Perhaps
> the two latter categories mix together.
>
> I guess my biggest problem is that the roles of concept, attribute, and
> modifier are partly defined by syntax (where they appear in the string)
and
> partly by having to know what names (em, pos, flux) have been allocated to
> which category.  This seems very arbitrary (and very confusing) to me.
> Although I have never written a parser in my life, it looks to me like a
> parser for this would be a zillion if statements.  Maybe this is fewer if
> statements than for other approaches, but it still looks very complex.
>
I agree that this is a major issue, although my biggest concern with it is a
little
different.  I'm giving a long answer to help me organize my thoughts.

The writer of a table presumably has access to the documentation for
UCDs so it shouldn't be a big problem dealing with the three types -- 
especially
once there are examples.  The problem is more in using UCDs when reading
tables.

In practice I'm not sure this would be a big deal for 'real' tools.  E.g.,
something like
VOPlot is going to need to know about the value and meas.error attributes
internally so
that it can plot values and error bars for a given quantity.  I.e., it's
just
going to look for pairs of columns within the same group of the form:
     SomeString;value and  SomeString;meas.error
A spectral processing tool is going to look for pairs like phot.flux*;value
and
phys.wavelength;value.  Specific tools internalize this kind of knowledge -- 
or
even better read it in as a data model.  These tools don't really know about
how
UCDs are organized.  The organization is intended to make it easy for them
to
search for the appropriate strings, but they just take advantage of that.

Generic tools for manipulating UCDs and for validating them are where the
problem
really begin to show up. Currently there are only 6 trees that are not basic
concepts
(em, frame and intent for modifiers and filter, stat and meas for
attributes).
I think the single word attributes are important enough that they will
not cause a problem.  So a complete algorithm to determine what word
belongs in what vocabulary is currently pretty easy... Psuedocode is just:

     firstAtom = substring(ucd, index(ucd,"."))
     switch (firstAtom) {
         'em', 'frame','intent': return thisIsAModifier
         'stat','filter','meas': return thisIsAnAttribute
         'value','local','instance','multiplet', 'vector': return
thisIsAnAttribute
     }
     return thisIsAConcept

Alternatively we're talking about validating UCDs against an IVOA schema to
define
the valid words and the match against this could give the type.

There are other simple ways to deal with this:  Begin all modifiers with m.
and attributes
with a.  Or I've suggested in the draft that all modifiers could be in the
frame tree
-- the idea is that the role of modifiers is to limit the context to which
the concept applies.
I don't think the attribute trees join as easily but if it's important
enough we could
pick a name for all of the attribute trees.

The biggest problem is non-standard namespaces.  How do we handle a new UCD
tree?
In some sense the issue is moot.  Non-standard words shouldn't be used
outside
of some developers local context.  They can be responsible for handling
them.  However
I suspect that non-standard words will escape into the wild.  The validate
against
the schema approach still works, but it's impossible for writers for tables
to know
how to use these UCDs.

There are some other ideas that might help address this issue:  Your
suggestion
of another separator character is nice.  I thought about it but decided that
it was too radial a change.  Maybe separate atributes and modifiers
within themselves by commas but separate them by '-'s.
e.g., a complex UCd might be:
     flux.phot-em.optical,intent.calculated-meas.error,stat.max
I'd still like to keep the vocabularies separate, but now it's trivial to
parse the UCD.

For the moment I tried to minimize the change from the original proposal.
Note that this
is all much harder in the original proposal.  There is no way to tell what
anything after
the first word is.  In that proposal the first word is a property, but all
subsequent
words can be either properties or concepts.  Nor there any lexical
definition of what
a property is (i.e., any word can be a property).



> The document has a lot of signs of a rush job -- is it Uniform or Unified?
> (Unified, I think.)

I always thought it was Uniform so that wasn't a typo but an error or my
part...
Sigh...

Is flux a 0-level concept?  Or is it phot.flux?
That I think is fixed in the published version (it's always phot.flux)

On p.
> 3 you say that units are not part of UCDs, but on p.16 you create a UCD,
> phys.degrees;value

I wasn't quite sure what the UCD should be there.
Maybe phys.angle.separation;value?

, that is all about units.  On p.12, I really like the
> typo(?) in 'pudding' (pubbing).

Alas that is also fixed.  [That kind of error must reflect some curious
things about the mind.  I clearly picked the mirror image letter even
though the typing motion for it is nothing like 'd']
>
> I'm not sure how others have reacted -- have not gone to the UCD list yet
to
> see.  But I was particularly confused by the following things.
>
> o  p.4, you say that
>
>     phot.flux;em.optical;intent.calculated;value
>
> is equivalent to
>
>     phot.flux;intent.calculated;em.flux;value
>
> But there must be a mistake here.  Shouldn't 'flux' in the second line be
> 'optical'?  And isn't the first form illegal if alphabetical order is
> required?

The typos in the UCD were fixed and I hope that would help clarify what
I was trying to say.  The two UCDs should have been
    phot.flux;em.optical;intent.calculated;value
and
    phot.flux;intent.calculated;em.optical;value
The statement I was trying to make was that there is no natural reason to
prefer one of these to the other, so we had to choose an arbitrary rule
to try to ensure uniqueness of UCDs.  Thus indeed the second is illegal.

>
> I find the goal of brevity at conflict with the goal of clarity.  What
does
> 'em' mean to a human reader?  Why 'src' and not 'source'?  Why 'value' and
> not 'scalar' (parallel structure to 'vector')?  Why default on 'value' in
a
> otherwise well-defined ontology?
I can't really argue with most of these.  The tension between various goals
it why I tried to list them all together.  I would be happy to change to
longer
words.

The default for value was just meant to be a convenience for writers of
tables.
If it confuses things I'm happy to drop it.

I like value rather than scalar because a value can be a vector quantity.
E.g.,
if we have a cell that contains an array of fluxes it's UCD might be
    phot.spectrum;value
That's because the concept of spectrum is inherently non-scalar.  A field
that had
a UCD of
    phot.spectrum;vector
would imply that each cell contained an array of spectra (i.e, that the cell
was
presumably a 2-d array).  However this is no big deal.


>
> I think if a clear distinction is to be made between attributes and
> modifiers, it must be encoded explicitly (i.e., not just based on a list
of
> magic words).  I do not like the semicolons as delimiters; this is not
what
> they mean in English grammar.  (The semicolon in the last sentence was
used
> properly.  The second clause is not necessarily a direct modifier of the
> first, but rather is related in some intimate way.)

This is fine by me -- I gave an example above using different separators.  I
think
the grammar is just as simple.

>
> I don't understand how to use the concept 'concept' in a practical sense.
>

Well I tried to give two examples:  If you have a VOTable in an editor how
do you
find the fields that don't have a defined concept?  If a user simply omits
the
UCD field it's kind of painful to find them.  However one can just do a
string
search for "concept" if the user has entered ucd='concept;value' to
explicitly
mark that the underlying UCD is unknown.

The real reason is given in the last example in section 5.  When correlating
two
tables that describe different kinds of quantities, e.g., sources and
observations,
I need to be able to describe what the ouput table is.   There are two
objects
in every row so it's a multiplet (in my scheme), but what kind of multiplet?
I can't
call it a source, and I can't call it an observation, so I need to go up to
a more
generic word, i.e., concept.  Basically it just provides the root for entire
concept
hierarchy.  If we really wanted to be regular, we could start all of the
base
concepts as using this word...

> Your definition of 'pos' does not include solar or planetary coordinate
> systems, though later you give an example that does.

I don't know what the current hierarchy under pos is...  What I'd guess
is that it would contain something like:

     pos.body.lat and pos.body.lon

and then the frame modifier would be used to specify which body.
[Or maybe I left an inconsistency in from the previous version]

>
> 'intent' is defined as the 'human context' of the concept.  Huh?  How are
> 'calculated', 'predicted', and 'simulated' anymore human concepts than
> 'observed' or 'measured'?

Observed and measured would be fine additions here except that they are
likely to be considered the default.  I.e., a time.exposure;value
is assumed to be the measured time, so I don't need to put that in.
[Note that meas is short for measurement].  The explanation probably needs
to be better, but I think we need some kind of modifier that distinguishes
between 'real' values and predicted, scheduled, calculated, ... values.
This
doesn't come up so much in VizieR tables, but many of the tables that I
deal with are riddled with situations where I may have an allocated exposure
time,
a predicted exposure time and an actual exposure time.  So something is
assumed to be actual/measured/observed unless an intent is specified.
>
> In 4.4 you insist that full words should be used ('electron' instead of
> 'el'), but at the same time assert that 'phys', 'temp', 'em', etc., are
all
> ok.

I don't have a horse in this race...  I tried to match the usage of the
previous
paper, but I'd be happy to go either way.
>
> Example 2 (p.14) does not convey to me anything semantically different if
I
> disregard your comments.  How am I supposed to understand something about
> guide stars and plate centers from the structure of the UCDs alone?  I
take
> issue with your assertion that "both software and humans should have no
> trouble distinguishing the very different semantics of the two tables."
>
Well...  I'd hope that by looking at the table UCD, you would immediately
note that one table returned source information and the other returned
observation information.  That's no small matter.  The structure immediately
shows which concept is subordinate to the other.  The actual semantics of
the relationship were not described.  You could do that if you want that
level
of detail.  I'm not sure what the right UCDs are.

E.g., in the source table might have included (hope the indentation survives
the mail):

      obs.instance
           meta.id;value
            pos;meas.center
                 pos.eq.ra;value
                 pos.eq.dec;value

I guess if we really want to include the concept of a guide star in the
UCD hierarchy, they probably belong in the base concept or maybe
in frame somehow, but I think this is
too detailed.  If we went ahead with it...  The guide star might be

      src;frame.usage.guiding;instance
meta.id;value
pos.instance

Note that in the first case it's the position that got the
extra information, because the observation is just a standard observation
(as far as we know).  In the second case we're suggesting that
this is a special kind of source.

But I don't think I want to put that in the relatively simple examples.
What I was trying to show was how the need for main columns has disappeared
and that we could get source or observation information from either table
with equivalent ease.

> I don't like 'arith' as a concept.  'math' would be ok.  If we need it at
> all.

Well I did try to discourage it...  I have no problem with math.
>
> I don't like 'soft' as a concept.  Is it so bad to just say 'software'?
All
> this stuff will be encoded in XML, which is notoriously verbose.  If we
> chose unclear abbreviations we will obscure whatever semantic meaning is
to
> be found.

Fine with me...

>
> OK, a lot of these criticisms are not really directed to you, but to the
> predecessor document.  I understood your presentation in Strasbourg (I
> thought) but do not follow the document sufficiently well that I would
ever
> be comfortable promoting it forward.  I did not like Roy and Sebatien's
> premise that concept and property could morph, one into the other,
depending
> on context.  I do like your attempt to structure things more rigidly.  It
> seems to me not rigid enough.  And when I ran into phys.degrees I felt
like
> the whole thing was falling down around me.  The concept is an angular
> distance, which of course can be expressed in degrees, radians, arcsec,
etc.

Agreed...  {see above)
>
> It might be worth our time to look at the AIPS++ measures definitions.  If
I
> were to construct a quick hierarchy, what we are trying to do here is
> distinguish various sorts of measurements, metadata about those
> measurements, and metadata about the people/organizations associated with
> those measurements.  So our fundamental concept is a measurement, of which
> there are various sorts:
>
> measurement
>   photometric
>   spectroscopic (which is just photometric per wavelength in an ordered
sort
> of way)
>   astrometric ('pos')
>   temporal
>   instrumental
>
> Ancillary information about measurements comes in the form of metadata:
>
> metadata
>   identifiers
>   people
>   organizations
>
> And we may have some special classes:
>
> software
> source (to collect measurements of an object in space-time)
>
> Measurements are taken in bandpasses, and in certain coordinate frames,
and
> from either the real universe or from computer simulations.  A bandpass is
a
> 'frame' restricting coverage in the em-spectrum.  A coordinate frame
> describes a restriction on the spatial coverage.  The idea of 'intent' has
> nothing to do with anything; it is simply a mode of collecting
measurements.
>
> Allright, enough of my rantings for this evening.  I applaud your attempt
to
> add rationality to Roy and Sebastien's work, but feel we still have some
way
> to go.
>

Thanks...  I don't disagree with what you are saying and I hope that we
can a least reopen the discussion.

Tom


From owner-dal@eso.org  Wed Oct 22 19:49:07 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9MHiRKp010601
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 22 Oct 2003 19:44:27 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9MHiRlP010600
	for dal-outgoing; Wed, 22 Oct 2003 19:44:27 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9MHhqKp010439;
	Wed, 22 Oct 2003 19:43:52 +0200 (MEST)
Received: from othello.physics.gla.ac.uk (othello.physics.gla.ac.uk [130.209.204.200])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9MHhpB1024875;
	Wed, 22 Oct 2003 19:43:51 +0200 (CEST)
Received: from ptolemy.astro.gla.ac.uk ([130.209.45.140])
	by othello.physics.gla.ac.uk with esmtp (Exim 4.14)
	id 1ACN1Q-0008PO-QR; Wed, 22 Oct 2003 18:43:48 +0100
Received: from norman (helo=localhost)
	by ptolemy.astro.gla.ac.uk with local-esmtp (Exim 3.35 #1)
	id 1ACN1Q-0003Ho-00; Wed, 22 Oct 2003 18:43:48 +0100
Date: Wed, 22 Oct 2003 18:43:48 +0100 (BST)
From: Norman Gray <norman@astro.gla.ac.uk>
To: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
cc: ucd@ivoa.net, <dm@ivoa.net>, <dal@ivoa.net>
Subject: Re: A suggested revision for UCDs
In-Reply-To: <3F9588DF.3030805@lheapop.gsfc.nasa.gov>
Message-ID: <Pine.LNX.4.44.0310221828540.12116-100000@ptolemy.astro.gla.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -2.0 (--)
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1ACN1Q-0008PO-QR*bN0SIfGukkA*
X-Othello-SMTP: True
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Norman Gray <norman@astro.gla.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Greetings, all, and Tom in particular.

On Tue, 21 Oct 2003, Thomas McGlynn wrote:

> 
> A few minutes ago I uploaded a version of my suggested revised
> proposal for UCDs to the Twiki.  This is just a Word version since
> I don't have a PDF generator handy.  The URL is
>     http://www.ivoa.net/internal/IVOA/IvoaUCD/UCD-1.9.9b.doc

I've appended a (longish) set of comments below.  I've just noticed that
Bob has forwarded a long set of comments to the list.  I haven't read
those yet.

By the way, I notice that this announcement/discussion has been posted
to no fewer than _three_ lists, namely ucd, dm and dal.  It would be
at the very least neater if it were on only one -- ucd@ivoa.net is the
obvious one.  What do folk think -- are there folk on the other two
lists who have an interest in this and aren't on the ucd@ivoa.net
list?






I'm sure I'm not the only one to find Tom's proposal very
thought-provoking.  The suggestions bring up several new use-cases;
and the idea of the `local' atom in particular is valuable, and a
gap in the 1.9.9 proposals (though I'd put it in a different place).
I think there are very likely several places in the 1.9.9 proposals
which are underspecified, and some where I personally would probably
explain things slightly differently from Roy and Sebastien, but these
are editorial matters.

I have a few difficulties with some aspects of Tom's proposal, however,
which I'll discuss here, and add a few more general remarks at the end.
I'm speaking for myself of course, rather than the group of authors,
and thus it's probable that my opinion and interpretation of some 1.9.9
points is at variance with others in the group, or goes beyond what the
document aims to say (which would be a useful datapoint).




Most urgent, I think, is Tom's discussion, in his section 4.5, of the
distinction between his proposals and the 1.9.9 ones.  These are crucial,
since these criticisms are what would ultimately justify replacing the
1.9.9 proposals with Tom's more complicated ones.

In the 1.9.9 proposals, the function of a word is always the same:
some things such as `src' are concepts (and only concepts), and
every other word names a property.  The distinction is that
concepts can't have a value, but can have properties; and a property
always has a value.  Now, the property;concept _pair_ also names a
concept, which can therefore have properties in turn (this has the
same potential as Tom's proposals for generating long UCDs in
principle, but probably very unlikely in practice).  There will
doubtless be some rather formal language which makes this cast-iron,
but it's actually fairly intuitive once you get the property/concept
dichotomy and read `;' as `of a' or something like that.

Section 3.1 in the 1.9.9 proposals -- the crucial section of the document,
for which everything else is to some extent just scaffolding, and without
which the rest of the document makes rather less sense -- is what attempts
to describe this.  Perhaps that explanation needs work.  At any rate, I do
not believe that one has to sign up to the (basically ontology-inspired)
language in that section in order to use the UCDs thus justified.
Indeed, it might be useful for that section to be split into two, one to
communicate the underlying idea to folk who simply want to _use_ UCDs,
and another to reexpress it more formally for the ontology enthusiasts.

In his section 4.5, Tom also remarks that ``Indeed I'm not sure that any
string of words can be determined to be illegal in the old scheme''.
I'd probably agree in outline: there are significantly fewer rules
necessary in the 1.9.9 proposals than in Tom's proposals.  The only place
a base concept can go is in the right-most position, and thus you can't
have a concept sitting on its own, since the left-most position is the
name of the property, the value of which is the number/column/whatever
which has been annotated by this UCD (the syntactic mechanism for making
that annotation is outside of scope for the UCD proposals, I'd think).
Also, there are some property-concept pairs that make no sense, such
as stat.err;src.  But that's about it -- you don't need any more rules
than that.

Tom constructs an `arith.diff;arith.sum;phot.flux;...' UCD.  That does
look unwieldy (but note there's no need for parentheses in the 1.9.9
proposals), but I get the impression that the `arith' UCD tree was to
some extent a kite being flown, and I for one would be surprised if it
made it much beyond this version, partly because it would seem to encourage
such odd-looking UCDs.  Also, there's no tying of one table to another
in the 1.9.9 proposals -- I'd think that was out of scope for UCD (and
quite properly so: I'll mention this below).

The 1.9.9 proposals allow no ambiguity in the way that UCDs are
written: properties queue up in front of the single base concept, and
ordering matters, so that stat.max;stat.err;phot.flux is different
from stat.err;stat.max;phot.flux.




More specific points in Tom's proposal, in document order rather than
any other (section references are to Tom's document):

Section 4.1: Bringing the number of terms up to three -- concept,
attribute and modifier -- reminds me of the qualifier/modifier idea
that was in previous versions of the draft, which I still think is an
unstable distinction, and which Roy and Sebastien thankfully managed
to get rid of by simplifying the syntax down to just concept plus
properties (but see below).  Also, there's no syntactic distinction
between modifiers and attributes, so in order to apply the extra
ordering rules for those, or even to break the UCD into its three
parts, you have to know which words are of which type.  That is, you
can't do it at parse time.

Section 4.1.2 (not an important point, I don't think): I'm puzzled at
the requirement that words in the non-standard namespace must be
distinct from all words in the IVOA namespace.  The point of having a
namespace is to make this possible, or (since such duplication would
surely be condemned as bad practice) at least not an error.  The rule
also means that if a new word were added to the IVOA namespace which
happened to match a word in a private namespace, the namespaced UCDs
would thereby suddenly become invalid, with no change in the spec.

Section 4.2.2: The `intent' modifier has no corresponding notion in
the 1.9.9 proposals, but it's not clear to me where in those proposals
this would fit in, and I think this is a _problem_ for the 1.9.9
proposals.  I can see how it would fit in to what I take the
underlying 1.9.9 model to be, but not into the serialisation of that
model that the 1.9.9 syntax represents.  I can see three approaches to
this problem within the general framework of the 1.9.9 proposals.  (i)
Rule it out of scope: it's not UCD's problem to talk about what values
are intended to be, since they're only for data discovery, and are not
required to be capable of driving analysis, so that if this `intent'
distinction matters to you, you're going to have to understand the utype
somehow.  (ii) Add modifiers like this to the 1.9.9 model and syntax:
that's potentially quite a lot of work, since it would require
thinking very clearly about just what the distinction is between
modifiers and properties, _and_ working out a usable syntax for adding
them in -- they _have_ to be distinguishable at parse time.  (iii)
Think about it more and discover a way they can be viewed as
properties in a principled way.  The point isn't just about this
`intent' modifier: if we can convince ourselves that there are things
like `intent' (and that they're in scope) which are in principle
qualitatively distinct from properties (and I would at least dispute
that `em' and `frame' count here), then that has to be dealt with.
Perhaps this example will help us find the stable distinction between
`qualifiers' and `modifiers' that escaped us in earlier versions.

Section 4.2.3: The `value', `vector', `instance' and `multiplet'
attributes seem overly complicated.  The `value' attribute is not
required in the 1.9.9 proposals because all properties have a value,
namely the value they're being used to annotate.  The other three seem
artefacts of the `complex UCDs' which Tom is introducing in these
proposals.  These complex UCDs seem problematic to me because they
seem tightly bound to VOTable.  That destroys the orthogonality of the
UCD and VOTable specs (the W3C has had _terrible_ trouble with
non-orthogonal specs, tying itself in knots trying to resolve their
dependencies on each other), and makes it harder to use UCDs in other
contexts, such as queries.  I feel that UCDs should be seen as
annotating a `thing', whether that `thing' be a value, a column, a
group, or a query `phrase', and it should be the responsibility of
whatever defines the syntax of that annotation (that is, VOTable or
SIA) to define precisely what the thing is that the annotation applies
to.  Thus, VOTable might say that when a UCD appears in a <field> then
it indicates a set of relationships between the corresponding entries
of the table; when it appears in a <group> it means something
different; and so on.  Dealing with the typing and complexity issues
of this in a general way within the UCD spec would surely make it
impossibly unwieldy and limit its scope.  This is also a general worry
for all of Tom's Section 5; I really think this should be out of scope
for UCD, to the extent that Tom's ``The grouping does not describe the
semantics of the relationship.  That is the role of UCDs'' would be
much better as ``The grouping describes (some of?) the semantics of
the relationship.  That is not the role of UCDs''.  This is a can of
worms.

Section 4.2.3 (local): I agree this is a gap in the 1.9.9 proposals.
Another way of dealing with it would be to say that a UCD <word>
`local.X' meant exactly the same as the <word> `X', but was not
comparable with it.





More general points:

Tom's document seems to discuss his proposals in object terms.
However the property-concept parts of the UCD proposal are _not_ an
object model, and if you cram them into an object model, they won't
fit, and the result will inevitably look like a mess, and look
backwards.  The model is simpler than this, however: things which are
purely concepts (such as `src') don't have values.  Concepts do have
properties though, and these properties have numeric values, namely
the numeric values we're trying to annotate with this UCD.

As regards ordering, yes, as Tom said, it doesn't fundamentally
matter, and it's just a matter of syntax, rather than of the model.
However having the property first seems natural, since it's this
which posesses the numerical value which is being annotated, and
so it's this which I would have thought it best would be shown
up-front.

Now, there is a _vague_ object model implicit in the construction of
the UCD words like `pos.eq.ra', but this is only because, along with
the replacement of underscores with dots, came the explicit freedom to
crop each word at a dot from the right, and use the result as a UCD
word also.  This prompts a natural perception of the words as
hierarchical, or object-oriented if you must.  The actual words are
basically little changed from the original UCDs, though there's a
review of these under way.  These words weren't the main point of the
UCD2 proposals.

At present these words are those mined from the column names actually
occurring in the databases in the CDS collection; they are thus
unprincipled.  Whether this is a good or a bad thing is an open question.
I'm sure it is this which causes some people (I'm thinking of Gerard
Lemson and Pat Dowler) to gasp and, in their poster, pick out pos_eq_ra
for special deprecation as incoherent.  If you believe that principled
generation of UCD words would be a Good Thing (and that would probably
be my prejudice), then I suspect that paths in (say) Gerard and Pat's
model would be a good way to do it (do Gerard and Pat claim that every
UCD word is thus expressible?).  If you believe, on the other hand, that
the mined nature of the words is of primary importance (and I can see
the force of that, too), then they might need little more than a review
or tidy-up, to make sure that the `croppability' is reasonable in fact,
and that the implications, or suggestions, of the words chosen do in
fact fit in with a properties-based model (or whatever we end up with).




Phew!  I think that's probably quite enough for just now -- I should
let someone else get a word in.

All the best,

Norman


-- 
---------------------------------------------------------------------------
Norman Gray                        http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK     norman@astro.gla.ac.uk

From owner-ucd@eso.org  Wed Oct 22 20:38:35 2003
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9MIYOKp029374
	for <ucd-outgoing@mercury.hq.eso.org>; Wed, 22 Oct 2003 20:34:24 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9MIYNrQ029373
	for ucd-outgoing; Wed, 22 Oct 2003 20:34:23 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9MIXkKp029151;
	Wed, 22 Oct 2003 20:33:46 +0200 (MEST)
Received: from mail630.gsfc.nasa.gov (mail630.gsfc.nasa.gov [128.183.190.39])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9MIXes3006523;
	Wed, 22 Oct 2003 20:33:40 +0200 (CEST)
Received: from gsfc.nasa.gov (ram.gsfc.nasa.gov [128.183.114.136])
	by mail630.gsfc.nasa.gov (8.12.8/8.12.5) with ESMTP id h9MIXaAM007111;
	Wed, 22 Oct 2003 14:33:36 -0400
Message-ID: <3F96CE02.8020804@gsfc.nasa.gov>
Date: Wed, 22 Oct 2003 14:35:46 -0400
From: Ed Shaya <Edward.J.Shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Shaya <Edward.J.Shaya.1@gsfc.nasa.gov>, dm@ivoa.net, dal@ivoa.net,
   ucd@ivoa.net
Subject: UCD changes on top of McGlynn's changes
Content-Type: multipart/mixed;
 boundary="------------010506050500090703000306"
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Ed Shaya <Edward.J.Shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

This is a multi-part message in MIME format.
--------------010506050500090703000306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I have made numerous tracked changes in the 1-9.9b of McGlynn and 
created a 1-9.9c.
So if one has a recent version of Word one can accept or reject these 
changes as seen fit. I think someone will need to post this to the UCD 
and dal lists cause I am not on them. Here are some "highlights"
--------------------------------------------------------------------------

The term property was used in a confusing manner.  Everything was at 
some point in the specification referred to as a property including the 
basic concept as well as the attribute and modifier.  So, I changed  
attribute property to attribute and modifier property to modifier.

I think this is pretty good but it is missing something.  The modifiers 
are in effect extending the hierarchicial tree of basic concepts into 
the virtual tree of full concepts.   This is not mentioned and probably 
should be. But, if it is true then sometimes the order of the modifiers 
should make a difference.   I don't have an example but I am worried 
that there will be concepts that require A;B;C and other concepts that 
are A;C;B but they are not the same.  I don't see how to ensure that 
that never happens.
------------------------------------------------------------
Word and atom were a bit confused. Atoms looked like words to me and 
Words were
clearly composed of several words (not good).  There was no atom in the 
Backus-Naur notation. But there were examples of atoms of the physics 
type (yikes).
So I made the following simplification.
atom -> word
word -> term
word-component -> word

-----------------------------------
I changed a few occurrence of "column" to "contents" so that it did not 
seem that this
was for tables only.  And so the Contents in "UCD" would be meaningful.
--------------------------------------
Why is there a meas.error and a stat.erro, and one is a concept and one 
is an attribute?
Perhaps this was suppose to be a stat:max?

1        x1:experimental.quantity;x2:new.modifier;stat.error


----------------------------------------------------

Why not have a different symbol to separate the attributes from the base 
and modifiers?
pos.eq;phys.electron#value;vector
pos.eq;phys.electron#stat.error;vector
This is clearer.  It says, if you are looking for instances of the 
concept  of a positional measure of electrons, here it is.  By the way 
it is in vector format and there is an error associate with it, you  may 
need to transform this format.  Queries will be keying on the concept 
and so it should be cleanly separated.  If the query finds additional 
attribute information  it may  grab them  for completeness even if they 
were not specificied in the query.

---------------------------

Why not allow a namespaced term to reuse existing term?  That is what 
namespace is for!


1        phot.flux;x1:meas.error       Namespace reuses existing 
term--------------------------
In the Group of pos.eq.ra and pos.eq.dec the UCD of the group should be 
pos.eq, not pos.instance.  The "eq" is there because one should be as 
specifying as possible.  The instance should not be there since this is 
a table level term and is redundant here.
------------------------------------------------------------
I don't buy the idea that the main pos is always in the least indented 
or grouped column.  This is a extremely fragile and restrictive way to 
go.  There are many ways that the targets are in a  more groups than the 
plate positions or the guide stars.  What if the target stars have 
position groups
and so one wants a second grouping of

<group name="position" ucd="position">
           <group name="positionEquatorial" ucd="pos.eq">
                          ra, dec
          </group>
          <group name="positionGalactic" ucd="position.galactic">
                         l,b
            </group>
</group>
or what if the grouping of stars is by cluster or by spectral type or 
by  accuracy of measurements  etc?
That is not to say that I like the idea of a main UCD.
Rather, the best way is to ensure that the structural container of the 
data has a way of refering the properties to the objects that has these 
properties.  A quanitty needs to have a isPropertyOf attribute that 
refers to the object.  So, a positional property column should have 
isPropertyOf="column(starName)".  The default could be 
isPropertyOf=column(1). 

---------------------------------------------------------
Finally.  I find it curious that this system makes no descrimination between
properties of objects (color, brightness, distance, size) and objects 
(electrons,
atoms, planets, stars, galaxies).  Every time one uses a UCD-property there
must be implicitly a UCD-object that has been left off.  A brightness is
always of a star or a planet or a human.  A query system must then be 
able to
infer this from other metadata in the dataset. Therefore one needs to 
ensure that every data set has somewhere atleast one UCD-object.  This 
will be hard to do if they are
not somehow separated out  I just wanted to point that out.
It may or may not be a fatal flaw.

Ed

 
               

 


--------------010506050500090703000306
Content-Type: application/msword;
 name="UCD-1.9.9c.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="UCD-1.9.9c.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAGAAAA8AIAAAAA
AAAAEAAA8gIAAAEAAAD+////AAAAAOoCAADrAgAA7AIAAO0CAADuAgAA7wIAAP//////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////spcEAVUAJBAAA+BK/AAAAAAAAEAAAAAAABgAA
hOIAAA4AYmpiaqybrJsAAAAAAAAAAAAAAAAAAAAAAAAJBBYAXvABAM7xAADO8QAAVNoAAAAA
AAAtAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A
AAAAAAAAAAAAAAAAAAAAAIgAAAAAAOQMAAAAAAAA5AwAAOQMAAAAAAAA5AwAAAAAAAA0DQAA
AAAAADQNAAAAAAAANA0AACQAAAAAAAAAAAAAAFgNAAAAAAAAgMEAAAAAAACAwQAAAAAAAIDB
AABQAAAA0MEAAHwBAABMwwAAtAIAAFgNAAAAAAAAiVwBACQCAAAMxgAA7gAAAPrGAAA0AAAA
LscAAAAAAAAuxwAAAAAAAEbHAAAAAAAAkcgAAAAAAACRyAAAAAAAAJHIAAAAAAAA6lsBAAIA
AADsWwEAAAAAAOxbAQAAAAAA7FsBAAAAAADsWwEAAAAAAOxbAQAAAAAA7FsBACQAAACtXgEA
UgIAAP9gAQDCAAAAEFwBABUAAAAAAAAAAAAAAAAAAAAAAAAANA0AAAAAAACu1QAAAAAAAAAA
AAAAAAAAAAAAAAAAAACNyAAABAAAAJHIAAAAAAAArtUAAAAAAACu1QAAAAAAABBcAQAAAAAA
AAAAAAAAAADkDAAAAAAAAOQMAAAAAAAALscAAAAAAAAAAAAAAAAAAEbHAABHAQAAJVwBACgA
AAB28AAAAAAAAHbwAAAAAAAAdvAAAAAAAACu1QAAPBAAAOQMAAA4AAAALscAAAAAAAA0DQAA
AAAAAEbHAAAAAAAA6lsBAAAAAAAAAAAAAAAAAHbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArtUAAAAAAADqWwEAAAAAAHbwAAB+AAAA
dvAAAAAAAAD08AAAngMAAIhIAQD0AgAAHA0AABgAAAA0DQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMk4BAAAAAAAuxwAA
GAAAAADGAAAMAAAAADah5caYwwEAAAAAAAAAAIDBAAAAAAAA6uUAAGAHAAB8SwEAmgAAAAAA
AAAAAAAAXlEBAIwKAABNXAEAPAAAAIlcAQAAAAAAFkwBABwCAADBYQEAAAAAAErtAAAQAwAA
wWEBAJAAAAAyTgEAAAAAAAAAAAAAAAAAWA0AAAAAAABYDQAAAAAAAOQMAAAAAAAA5AwAAAAA
AADkDAAAAAAAAOQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMFhAQAAAAAAAAAAAAAAAAA0DQAA
AAAAADJOAQAsAwAADdUAABQAAAAh1QAADgAAAHbwAAAAAAAAL9UAAAwAAAA71QAAcwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkcgAAIwJAAAd0gAA9AEAABHUAAD8AAAA
EFwBAAAAAAAQXAEAAAAAAFgNAAAAAAAAWA0AAORaAAA8aAAARFkAAAAAAAAAAAAAWvAAABwA
AABYDQAAAAAAAFgNAAAAAAAAPGgAAAAAAAACAAEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1UaGlzIGlzIHRoZSByZXZpc2VkIHZlcnNpb24gdGhh
dCBJIHByb21pc2VkIGF0IHRoZSBJbnRlcm9wZXJhYmlsaXR5IFdvcmtzaG9wLiAgSSBoYXZl
IHN1YnN0YW50aWFsbHkgY2hhbmdlZCB0aGUgY29udGVudCBhbmQgc2NvcGUgb2YgdGhpcyBk
b2N1bWVudCBpbiB3YXlzIHRoYXQgZ28gd2VsbCBiZXlvbmQgdGhlIGlzc3VlcyBkaXNjdXNz
ZWQgZGlyZWN0bHkgaW4gdGhlIFVDRCB3b3JraW5nIGdyb3VwIG1lZXRpbmcuICBUaGVzZSBj
aGFuZ2VzIGFyZSByZWZsZWN0ZWQgcHJpbWFyaWx5IGluIHNlY3Rpb24gNS4gIEkgaGF2ZSBp
bmNsdWRlZCBzb21lIGNvbW1lbnRhcnkgb24gdGhlIHRleHQgd2l0aGluIHRoZSBkb2N1bWVu
dC4gIFRoaXMgdGV4dCBpcyBnZW5lcmFsbHkgZ2l2ZW4gaW4gcmVkIGFuZCB3b3VsZCBiZSBl
bGltaW5hdGVkIGV2ZW4gaW4gdGhlIHVubGlrZWx5IGV2ZW50IHRoYXQgdGhpcyBwcm9wb3Nh
bCB3ZXJlIGFjY2VwdGVkIHdpdGhvdXQgY2hhbmdlLiAgVGhlIGNvbW1lbnRhcnkgbWF0ZXJp
YWwgaW5jbHVkZXMgZGlzY3Vzc2lvbiBvZiAgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGlzIHBy
b3Bvc2FsIGFuZCB0aGUgcHJldmlvdXMgb25lLiBUaGVyZSBpcyBhIHN1bW1hcnkgb2YgdGhp
cyBhZnRlciBzZWN0aW9uIDQuIA0NAQ0NTWV0YWRhdGEgQ29udGVudCB3aXRoaW4gVk8gUmVz
b3VyY2VzDVZlcnNpb24gMS45LjliDQ1JVk9BIFdvcmtpbmcgRHJhZnQNMjAwMy0xMC0yMQ1Q
cmV2aW91cyB2ZXJzaW9uczogCTEuOS45ICgyMDAzLTEwLTAyKQ1BdXRob3JzOg1T6WJhc3Rp
ZW4gRGVycmllcmUgPBNIWVBFUkxJTksgIm1haWx0bzpkZXJyaWVyZUBuZXdiNi51LXN0cmFz
YmcuZnIiARRkZXJyaWVyZUBuZXdiNi51LXN0cmFzYmcuZnIVPgtOb3JtYW4gR3JheSA8E0hZ
UEVSTElOSyAibWFpbHRvOm5vcm1hbkBhc3Ryby5nbGEuYWMudWsiARRub3JtYW5AYXN0cm8u
Z2xhLmFjLnVrFT4LQm9iIE1hbm4gPBNIWVBFUkxJTksgIm1haWx0bzpyZ21Acm9lLmFjLnVr
IgEUcmdtQHJvZS5hYy51axU+C0FuZHJlYSBQcmVpdGUgTWFydGluZXogPBNIWVBFUkxJTksg
Im1haWx0bzphbmRyZWFAcm0uaWFzZi5jbnIuaXQiARRhbmRyZWFAcm0uaWFzZi5jbnIuaXQV
PgtKb25hdGhhbiBNY0Rvd2VsbCA8E0hZUEVSTElOSyAibWFpbHRvOmpjbUBjZmEuaGFydmFy
ZC5lZHUiARRqY21AY2ZhLmhhcnZhcmQuZWR1FT4LVGhvbWFzIE1jR2x5bm4gPDxUaG9tYXMu
QS5NY0dseW5uQG5hc2EuZ292PgtGcmFu529pcyBPY2hzZW5iZWluIDwTSFlQRVJMSU5LICJt
YWlsdG86ZnJhbmNvaXNAdml6aXIudS1zdHJhc2JnLmZyIgEUZnJhbmNvaXNAdml6aXIudS1z
dHJhc2JnLmZyFT4LUGVkcm8gT3N1bmEgPBNIWVBFUkxJTksgIm1haWx0bzpQZWRyby5Pc3Vu
YUBlc2EuaW50IgEUUGVkcm8uT3N1bmFAZXNhLmludBU+C0d1eSBSaXhvbiA8E0hZUEVSTElO
SyAibWFpbHRvOmd0ckBhc3QuY2FtLmFjLnVrIgEUZ3RyQGFzdC5jYW0uYWMudWsVPgtSb3kg
V2lsbGlhbXMgPBNIWVBFUkxJTksgIm1haWx0bzpyb3lAY2Fjci5jYWx0ZWNoLmVkdSIBFHJv
eUBjYWNyLmNhbHRlY2guZWR1FT4NQWJzdHJhY3QNVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFu
ZCBkZXNjcmliZXMgdGhlIHN0YW5kYXJkIG1ldGhvZCBmb3IgaW5jb3Jwb3JhdGluZyBtZXRh
ZGF0YSBjb250ZW50IGRlc2NyaXB0b3JzIHdpdGhpbiBWaXJ0dWFsIE9ic2VydmF0b3J5IGVu
dGl0aWVzLiAgSW4gSXQgaW5jbHVkZXMgYm90aCB0aGUgZGVmaW5pdGlvbiBvZiB0aGVzZSBV
bmlmb3JtIENvbnRlbnQgRGVzY3JpcHRvcnMgKFVDRHMpIGFuZCBzcGVjaWZpYyByZWNvbW1l
bmRhdGlvbnMgZm9yIGhvdyB0aGVzZSBxdWFudGl0aWVzIHNob3VsZCBiZSB1c2VkICB3aXRo
aW4gdGFidWxhciBpbmZvcm1hdGlvbi4gIFdoaWxlIHVzZSBpbiB0YWJ1bGFyIGRhdGFzZXRz
IGlzIGhpZ2hsaWdodGVkLCBVQ0RzIG1heSBiZSB1c2VkIGluIG90aGVyIGNvbnRleHRzLg0N
U3RhdHVzIG9mIHRoaXMgZG9jdW1lbnQNVGhpcyBpcyBhbiBJVk9BIFByb3Bvc2VkIFJlY29t
bWVuZGF0aW9uIGZvciByZXZpZXcgYnkgSVZPQSBtZW1iZXJzIGFuZCBvdGhlciBpbnRlcmVz
dGVkIHBhcnRpZXMuIEl0IGlzIGEgZHJhZnQgZG9jdW1lbnQgYW5kIG1heSBiZSB1cGRhdGVk
LCByZXBsYWNlZCwgb3Igc3VwZXJzZWRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IHRp
bWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElWT0EgV29ya2luZyBEcmFmdHMgYXMg
cmVmZXJlbmNlIG1hdGVyaWFscyBvciB0byBjaXRlIHRoZW0gYXMgb3RoZXIgdGhhbiAid29y
ayBpbiBwcm9ncmVzcy4iIEEgbGlzdCBvZiATSFlQRVJMSU5LICJodHRwOi8vd3d3Lml2b2Eu
bmV0L0RvY3VtZW50cy8iARRjdXJyZW50IElWT0EgUmVjb21tZW5kYXRpb25zIGFuZCBvdGhl
ciB0ZWNobmljYWwgZG9jdW1lbnRzFSBjYW4gYmUgZm91bmQgYXQgaHR0cDovL3d3dy5pdm9h
Lm5ldC9Eb2N1bWVudHMvLiANDVRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSByZXZpc2lvbiB0
byBhbiBhY2NlcHRlZCBVQ0Qgdm9jYWJ1bGFyeS4gIFRoaXMgcmV2aXNpb24gaXMgbm90IGNv
bXBhdGlibGUgd2l0aCB0aGUgZXhpc3Rpbmcgdm9jYWJ1bGFyeS4gIEFjY2VwdGFuY2Ugb2Yg
dGhpcyBkb2N1bWVudCBhcyBhIHJlY29tbWVuZGF0aW9uIGltcGxpZXMgY2hhbmdlcyB0byBl
eGlzdGluZyBzb2Z0d2FyZSBhbmQgb3RoZXIgaW5mb3JtYWwgYWdyZWVtZW50cyBpbmNsdWRp
bmcgdGhlIENvbmUgU2VhcmNoIGFuZCBTaW1wbGUgSW1hZ2UgQWNjZXNzIFByb3RvY29scyBz
aW5jZSB0aGVzZSB1c2UgVUNEcyBpbmNvbXBhdGlibGUgd2l0aCB0aGUgcHJvcG9zZWQgc3Rh
bmRhcmQuDSBBY2tub3dsZWRnbWVudHMNVGhpcyBkb2N1bWVudCBpcyBiYXNlZCBvbiB0aGUg
VzNDIGRvY3VtZW50YXRpb24gc3RhbmRhcmRzLCBidXQgaGFzIGJlZW4gYWRhcHRlZCBmb3Ig
dGhlIElWT0EuDQ00LiBVbmlmb3JtIENvbnRlbnQgRGVzY3JpcHRvcnM6IEEgQ29udHJvbGxl
ZCBWb2NhYnVsYXJ5IGZvciBBc3Ryb25vbXkNVGhlIFVuaWZpZWQgQ29udGVudCBEZXNjcmlw
dG9yIChVQ0QpIGlzIGEgZm9ybWFsIHZvY2FidWxhcnkgZm9yIGFzdHJvbm9taWNhbCBtZXRh
ZGF0YSB0aGF0IGlzIGNvbnRyb2xsZWQgYnkgdGhlIEludGVybmF0aW9uYWwgVmlydHVhbCBP
YnNlcnZhdG9yeSBBbGxpYW5jZSAoSVZPQSkuICBFYWNoIFVDRCBkZXNjcmliZXMgYSBjb25j
ZXB0LCBhIGtpbmQgb2YgdGhpbmcgdGhhdCBtYXkgYmUgb2YgaW50ZXJlc3QgdG8gYXN0cm9u
b21lcnMgb3IgdXNlZnVsIHRvIFZPIHJlc291cmNlcy4gIFVDRCBjb25jZXB0cyBhcmUgYW5h
bG9nb3VzIHRvIGNsYXNzZXMgaW4gb2JqZWN0IG9yaWVudGVkIHByb2dyYW1taW5nLiAgSW4g
cGFydGljdWxhciB0aGUgVUNEIGRlc2NyaWJlcyB0aGUgdHlwZSBvZiB0aGUgdGhpbmcsIHRo
ZSBjb250ZW50IGl0IHJlZmVycyB0byBkZWZpbmVzIG9uZSBvciBtb3JlIGluc3RhbmNlcyBv
ZiB0aGUgZ2l2ZW4gY29uY2VwdC4gIEUuZy4sIEdhbGFjdGljIGxhdGl0dWRlIGlzIGEgY29u
Y2VwdCwgOyB0aGUgbGF0aXR1ZGUgb2YgdGhlIEdhbGFjdGljIGNlbnRlciB3aGljaCBoYXMg
dGhlIG51bWVyaWNhbCB2YWx1ZSBvZiAwLCBpcyBhbiBpbnN0YW5jZSBvZiB0aGlzIGNvbmNl
cHQuICBUaGUgVUNEIGNvbmNlcHQgdm9jYWJ1bGFyeSBpcyByZXN0cmljdGVkIGluIG9yZGVy
IHRvIGF2b2lkIHByb2xpZmVyYXRpb24gb2YgdGVybXMgYW5kIHN5bm9ueW1zLCBhbmQgY29u
dHJvbGxlZCBpbiBvcmRlciB0byByZWR1Y2UgYW1iaWd1aXR5IGFzIGZhciBhcyBwb3NzaWJs
ZS4NDVVDRHMgcGxheSBhIGNlbnRyYWwgcm9sZSBpbiByZXNvdXJjZSBkaXNjb3ZlcnkgYW5k
IHByb2Nlc3NpbmcgaW4gdGhlIFZpcnR1YWwgT2JzZXJ2YXRvcnkuICBTZXJ2aWNlcyBtYXkg
cHVibGlzaCB0aGUgVUNEcyB0aGF0IGRlc2NyaWJlIHRoZWlyIG91dHB1dHMuICBMb29raW5n
IGF0IHRoZXNlIFVDRHMgaHVtYW4gdXNlcnMgb3IgbWFjaGluZSBhZ2VudHMgY2FuIGZpbmQg
c291cmNlcyBvZiB0aGUgaW5mb3JtYXRpb24gdGhleSBhcmUgbG9va2luZyBmb3IuICBXaGVu
IGEgVk8gc2VydmljZSBuZWVkcyB0byBwcm9jZXNzIGFuIGVsZW1lbnQgb2YgZGF0YSBvYnRh
aW5lZCBmcm9tIGEgcmVtb3RlIHNpdGUsIHRoZSBVQ0RzIGd1aWRlIHRoZSBwcm9jZXNzaW5n
LiAgRXhpc3RpbmcgYW5kIHByb3Bvc2VkIFZPIHByb3RvY29scyB1c2UgVUNEcyBhcyB0aGUg
bWVjaGFuaXNtIHRvIGNvbnZleSB0byB1c2VycyB3aGVyZSBjcml0aWNhbCBpbmZvcm1hdGlv
biByZXNpZGVzLiAgVUNEcyBhbmQgdHJlZXMgb2YgVUNEcyBtYXkgYmUgdXNlZCB0byBleHBy
ZXNzIHRoZSByZWxhdGlvbnNoaXBzIGFtb25nIGRhdGEgY3JpdGljYWwgdG8gYnVpbGRpbmcg
ZWZmZWN0aXZlIGRhdGEgbW9kZWxzLg0NVUNEcyBhcmUgc2ltcGx5IGEgc3RyaW5nIHdpdGgg
YSBzdHJ1Y3R1cmUgZGVmaW5lZCBiZWxvdy4gIFRoZSBmb3JtYXQgb2YgdGhlIHN0cmluZyBi
YWxhbmNlcyBhIG51bWJlciBvZiBjb21wZXRpbmcgZ29hbHM6DVVDRHMgc2hvdWxkIGJlIHNo
b3J0Lg1UaGV5IHNob3VsZCBzdWdnZXN0IHRoZSBjb25jZXB0IGJlaW5nIGxhYmVsZWQuDU9u
bHkgYSBzaW5nbGUgVUNEIHNob3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgYSBnaXZlbiBjb25j
ZXB0Lg1UaGUgc2V0IG9mIFVDRHMgc2hvdWxkIGJlIGNvbXBsZXRlLCBkZXNjcmliaW5nIGFs
bCBjb25jZXB0cyBvZiBpbnRlcmVzdC4NVGhlIHZvY2FidWxhcnkgdXNlZCB3aXRoaW4gVUNE
cyBzaG91bGQgYmUgYXMgc21hbGwgYXMgcG9zc2libGUuDVRoZSBzdHJ1Y3R1cmUgb2YgVUNE
cyBzaG91bGQgcmVmbGVjdCB0aGUgcmVsYXRpb25zaGlwcyBvZiB0aGUgY29uY2VwdHMgdGhl
eSBsYWJlbC4gIFJlbGF0ZWQgY29uY2VwdHMgc2hvdWxkIGhhdmUgcmVsYXRlZCBVQ0RzLg1R
dWFudGl0aWVzIHdpdGggdGhlIHNhbWUgVUNEIHNob3VsZCBiZSBjb21wYXJhYmxlLiAgVGhp
cyCRY29tcGFyYWJpbGl0eZIgbWF5IHJlcXVpcmluZyByZXF1aXJlIHJlc2NhbGluZyAsb3Ig
YWRqdXN0bWVudCBvciB1bml0IGNvbnZlcnNpb24gb2YgdGhlIHZhbHVlcyBvciBhdHRyaWJ1
dGVzIG9mIHRoZSBpbnN0YW5jZXMgYmVpbmcgY29tcGFyZWQuICAgQ29tcGFyYWJpbGl0eSBv
ZiBVQ0RzIGlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDQuNSwgaW5jbHVkaW5nIHRoZSBtZWFu
aW5nIG9mIGNvbXBhcmFiaWxpdHkgZm9yIFVDRHMgdGhhdCBkZXNjcmliZSBjb21wbGV4IGVu
dGl0aWVzLg0NQSBVQ0QgZGVzY3JpcHRpb24gb2YgYSBxdWFudGl0eSBkb2VzIG5vdCBkZWZp
bmUgdGhlIHVuaXRzIG9yIG5hbWUgb2YgdGhlIHF1YW50aXR5LCBidXQgcmF0aGVyICd3aGF0
IHNvcnQgb2YgcXVhbnRpdHkgaXMgdGhpcz8nOy4gZm9yIEZvciBleGFtcGxlIHBoeXMudGVt
cGVyYXR1cmUgaXMgYSBzZW1hbnRpYyBjbGFzcyBkZXNjcmlwdGlvbiBvZiAgdGVtcGVyYXR1
cmUsIHdpdGhvdXQgaW1wbHlpbmcgYSBwYXJ0aWN1bGFyIHVuaXQuICBJbnN0YW5jZXMgd2l0
aCB0aGUgc2FtZSBVQ0Qgc2hvdWxkIGhhdmUgdGhlIHNhbWUgZGltZW5zaW9uYWxpdHkgKGVn
IEZvcmNlIGlzIGFsd2F5cyBhIG1hc3MqbGVuZ3RoIHBlciBzZWNvbmQgcGVyIHNlY29uZCBh
bHRob3VnaCB0aGUgY2hvaWNlIG9mIHVuaXRzIG1heSB2YXJ5KS4uDUl0IHdvdWxkIGJlIHBv
c3NpYmxlIHRvIGRlc2NyaWJlIGFzdHJvbm9taWNhbCBkYXRhIHF1YW50aXRpZXMgaW4gYSBu
YXR1cmFsIGxhbmd1YWdlIHN1Y2ggYXMgRW5nbGlzaCBvciBIdW5nYXJpYW4gb3IgVXpiZWs7
IGhvd2V2ZXIsIGl0IHdvdWxkIGJlIHZlcnkgZGlmZmljdWx0IHRvIGV4cGVjdCBhIG1hY2hp
bmUgdG8gJ3VuZGVyc3RhbmQnIGluIGFueSBzZW5zZS4gQXQgdGhlIG9wcG9zaXRlIGV4dHJl
bWUsIHRoZXJlIGlzIGFuIGF0dGVtcHQgd2l0aGluIHRoZSBJVk9BIHRvIGRlc2NyaWJlIGFz
dHJvbm9taWNhbCBkYXRhIGluIHRlcm1zIG9mIGEgaGllcmFyY2hpY2FsIGRhdGEgbW9kZWws
IHNvIHRoYXQgdGhlcmUgaXMgYSBwbGFjZSBmb3IgZXZlcnl0aGluZywgYW5kIGV2ZXJ5dGhp
bmcgaXMgaW4gaXRzIHBsYWNlLiBUaGUgVUNEIHZvY2FidWxhcnkgZmFsbHMgYmV0d2VlbiB0
aGVzZSBleHRyZW1lcywgYW5kIGlzICh3ZSBob3BlKSB1bmRlcnN0YW5kYWJsZSB0byBib3Ro
IGh1bWFuIGFuZCBjb21wdXRlci4NDUkgaGF2ZSBkZWxldGVkIHRoZSBvcmlnaW5hbCBzZWN0
aW9uIDMuMSBzaW5jZSBJIGRvbpJ0IGJlbGlldmUgaXQgYWRkcyBhbnl0aGluZyB0byB0aGlz
IHNwZWNpZmljYXRpb24uICBJZiB3ZSBwbGFuIGEgVUNEIDMsIHRob3NlIGdvYWxzIG1pZ2h0
IGJldHRlciBiZSBkZWZpbmVkIGluIGEgY29uY2x1c2lvbiBvciBhcHBlbmRpeC4NNCwxIFVD
RCBTeW50YXgNQSBVQ0QgaXMgYSBzdHJpbmcgd2hpY2ggY29udGFpbnMgdGV4dHVhbCB0b2tl
bnMgdGhhdCB3ZSBzaGFsbCBjYWxsIHdvcmRzdGVybXMsIHdoaWNoIGFyZSBzZXBhcmF0ZWQg
Ynkgc2VtaWNvbG9ucy4gQSB3b3JkIHRlcm0gbWF5IGJlIGNvbXBvc2VkIG9mIHNldmVyYWwg
YXRvbXN3b3Jkcywgc2VwYXJhdGVkIGJ5IHBlcmlvZCBjaGFyYWN0ZXJzLiAgQSB3b3JkIGlz
LCBjb21wb3NlZCBvZiBsZXR0ZXJzLCBudW1iZXJzLCBhbmQgb3IgaHlwaGVucy4gQSB0ZXJt
IG1heSBiZSBuYW1lc3BhY2VkIGJ5IHByZWZpeCBvZiAgYSB3b3JkIHBsdXMgY29sb24gc2Vw
YXJhdGVkIGJ5IHBlcmlvZCBjaGFyYWN0ZXJzLiBUaGUgb3JkZXIgb2YgdGhlc2UgYXRvbXdv
cmRzIGluZHVjZXMgYSBoaWVyYXJjaHkuICBFLmcuLCB0aGUgc2V0IG9mIHdvcmRzIHRlcm1z
IHBvcywgcG9zLmVxIGFuZCBwb3MuZXEucmEgcmVmbGVjdCBpbmNyZWFzaW5nbHkgcHJlY2lz
ZSBjb25jZXB0cy4gU3RhbmRhcmQgd29yZHRlcm1zIHVzZWQgaW4gdGhlIFVDRCwgd2hpY2gg
YXJlIHZhbGlkYXRlZCBieSB0aGUgSVZPQSwgY2FuIHN0YXJ0IHdpdGggdGhlIGl2b2E6IG5h
bWVzcGFjZSwgYnV0IHRoaXMgbmFtZXNwYWNlIGlzIG9wdGlvbmFsLg1UaGUgY2hhcmFjdGVy
IHNldCB0aGF0IG1heSBiZSB1c2VkIGluIGEgVUNEIGlzIHRoZSB1cHBlciBhbmQgbG93ZXIt
Y2FzZSBhbHBoYWJldCwgZGlnaXRzLCBhbmQgaHlwaGVuLiBUaGUgY29sb24sIHNlbWljb2xv
biwgYW5kIHBlcmlvZCBhcmUgc3BlY2lhbCBjaGFyYWN0ZXJzIGFzIGRpc2N1c3NlZCBhYm92
ZS4gDVRoZSBVQ0Qgc3ludGF4IGlzIGNhc2UtaW5zZW5zaXRpdmUgliBhbGwgdXBwZXJjYXNl
IGNoYXJhY3RlcnMgc2hvdWxkIGJlIGNvbnZlcnRlZCB0byBsb3dlcmNhc2UgYmVmb3JlIHBh
cnNpbmcuDVRoZXJlIHNob3VsZCBiZSBubyB3aGl0ZXNwYWNlIHdpdGhpbiBhIFVDRC4NDUVh
Y2ggVUNEIGNvbnNpc3RzIG9mIGEgc2VxdWVuY2Ugb2Ygd29yZHRlcm1zIHdoZXJlIHRoZSBm
aXJzdCB3b3JkdGVybSBpcyBhIGJhc2UgY29uY2VwdCwgYW5kIGZvbGxvd2luZyBvcHRpb25h
bCB3b3JkdGVybXMgYXJlIHByb3BlcnRpZXNtb2RpZmllcnMsIGFuZCBmaW5hbCB0ZXJtcyBh
cmUgYXR0cmlidXRlcy4gIFByb3BlcnRpZXMgY29tcHJpc2UgdHdvIHR5cGVzOiBtb2RpZmll
cnMgYW5kIGF0dHJpYnV0ZXMuICBaZXJvIG9yIG1vcmUgbW9kaWZpZXJzIHdvcmRzIGltbWVk
aWF0ZWx5IGZvbGxvdyB0aGUgYmFzZSBjb25jZXB0LCBhbmQgdGhlc2UgYXJlIGZvbGxvd2Vk
IGJ5IG9uZSBvciBtb3JlIGF0dHJpYnV0ZSB3b3Jkcy4gIE1vZGlmaWVycyBhcmUgVUNEIGFk
amVjdGl2ZXMsIGNvbnN0cmFpbmluZyB0aGUgbWVhbmluZyBvZiB0aGUgYmFzZSBjb25jZXB0
LiAgICBBdHRyaWJ1dGVzIGRlZmluZSBhbiBhc3BlY3Qgb2YgdGhlIGNvbmNlcHQuICBGb3Ig
bWFueSBzaW1wbGUgY29uY2VwdHMgdGhlIG9ubHkgYXR0cmlidXRlIG1heSBiZSB0aGUgkXZh
bHVlki4gRS5nLiwgY29uc2lkZXIgYSBjb2x1bW4gY29udGVudCB0aGF0IHNpbXBsZSBzaW1w
bHkgY29udGFpbnMgYSBzZXQgb2YgZmx1eCBtZWFzdXJlbWVudHMuICBUaGUgdW5kZXJseWlu
ZyBjb25jZXB0IGlzIHBob3QuZmx1eCBhbmQgdGhlIFVDRCBpcyBwaG90LmZsdXg7dmFsdWUu
ICBBcyBhIGNvbnZlbmllbmNlIHRvIHRoZSB1c2VyIGluIHRoZSBjYXNlIHdoZXJlIHRoZSBV
Q0QgaXMgYSBzaW1wbGUgdHdvLXdvcmQgZm9ybSwgY29uY2VwdDt2YWx1ZSAgdGhlIHZhbHVl
IHByb3BlcnR5IGF0dHJpYnV0ZSBtYXkgYmUgb21pdHRlZC4gIEUuZy4sIHdlIG1heSB1c2Ug
cGhvdC5mbHV4IGFzIGFuIGFiYnJldmlhdGlvbiBmb3IgcGhvdC5mbHV4O3ZhbHVlLiAgSG93
ZXZlciBpbiBwaG90LmZsdXg7ZW0ucmFkaW87dmFsdWUgdGhlIHZhbHVlIGF0dHJpYnV0ZSBp
cyBtYW5kYXRvcnkuDQ1UaGUgdm9jYWJ1bGFyeSBvZiB3b3JkcyB1c2VkIHRvIGRlZmluZSBV
Q0RzIGNvbnNpc3RzIG9mIHRocmVlIGVsZW1lbnRzVGhlcmUgYXJlIHRocmVlIGNsYXNzZXMg
b2YgdGVybXM6IGJhc2UgY29uY2VwdHMsIG1vZGlmeWluZ2llcnMgcHJvcGVydGllcyBhbmQg
YXR0cmlidXRlcyBwcm9wZXJ0aWVzLiAgV29yZFRlcm1zIGJlbG9uZyB0byBvbmx5IG9uZSBv
ZiB0aGVzZSBjbGFzc2VzIGJ1dCB0aGUgY29tcG9uZW50IGF0b213b3JkcyB0aGF0IGNvbXBy
aXNlIHdvcmR0ZXJtcyBtYXkgYXBwZWFyIGluIGFueSBvZiB0aGUgdGhyZWUgdm9jYWJ1bGFy
aWVzY2xhc3Nlcy4gU3Vic2VxdWVudCBzZWN0aW9ucyBvZiB0aGlzIGRvY3VtZW50IGRlc2Ny
aWJlIGVhY2ggb2YgdGhlc2UgdGhyZWUgY2xhc3Nlc2VsZW1lbnRzIGluIHR1cm4uDVJlZmlu
ZWQgb3Igc3BlY2lhbCBjb25jZXB0cyBhcmUgYnVpbHQgaW4gc3RlcHMgZnJvbSBhIHNpbXBs
ZSBVQ0QuDQ1waG90LmZsdXgJQSBmbHV4IGluIHNvbWUgdW5kZWZpbmVkIGJhbmQgKHNob3J0
IGZvciBwaG90LmZsdXg7dmFsdWUpDXBob3QuZmx1eDtlbS5vcHRpY2FsO3ZhbHVlICAgICAg
ICAgCUEgZmx1eCBtZWFzdXJlbWVudCBpbiB0aGUgb3B0aWNhbCBiYW5kLiAgDXBob3QuZmx1
eDtlbSBvcHRpY2FsO21lYXMuZXJyb3IgLglUaGUgZXJyb3IgaW4gdGhlIGZsdXguICBUaGlz
IGlsbHVzdHJhdGVzIGEgZGlmZmVyZW50IGF0dHJpYnV0ZSBvZiB0aGUgZmx1eCBjb25jZXB0
LiAgVGhlIFVDRCBwaG90LmZsdXg7ZW0ub3B0aWNhbDttZWFzLmVycm9yIGlzIGFsc28gYSBj
b25jZXB0IGluIGl0cyBvd24gcmlnaHQgYW5kIHRodXMgbWF5IGJlIG1vZGlmaWVkLiANcGhv
dC5mbHV4O2VtLm9wdGljYWw7bWVhcy5lcnJvcjtzdGF0Lm1heAlPbmx5IGF0dHJpYnV0ZXMg
bWF5IGJlIGFwcGVuZGVkIHRvIGNvbXBsZXRlIFVDRHNBdHRyaWJ1dGVzIGFyZSBhbHdheXMg
YXQgdGhlIGVuZCBvZiBhIFVDRC4gIFRoaXMgb25lIGluZGljYXRlcyBhIGNvbHVtbiBvciBt
b3JlIGxpa2VseSBhIHBhcmFtZXRlciB0aGF0IGlzIHRoZSBtYXhpbXVtIGVycm9yIGluIHRo
ZSBmbHV4Lg1BIHdlbGwtZm9ybWVkIFVDRCBjb21wcmlzZXMgYSBiYXNlIHByb3BlcnR5LCAw
IG9yIG1vcmUgbW9kaWZ5aW5naWVycyBwcm9wZXJ0aWVzLCBhbmQgb25lIG9yIG1vcmUgYXR0
cmlidXRlcyBwcm9wZXJ0aWVzLiAgSWYgbW9yZSB0aGFuIG9uZSBtb2RpZmllciBpcyBpbmNs
dWRlZCB0aGVuIG1vZGlmaWVycyBzaG91bGQgYmUgZ2l2ZW4gaW4gYWxwaGFiZXRpY2FsIG9y
ZGVyLiAgVGhlIGNvbnN0cmFpbnQgb24gdGhlIG9yZGVyIG9mIG1vZGlmaWVycyBoZWxwcyB0
byBlbnN1cmUgdGhhdCBVQ0RzIGFyZSB1bmlxdWUuICBFLmcuLCBjb25zaWRlciB0aGUgVUNE
IGZvciBhIGNhbGN1bGF0ZWQgb3B0aWNhbCBmbHV4Og0gICAgcGhvdC5mbHV4O2VtLm9wdGlj
YWw7aW50ZW50LmNhbGN1bGF0ZWQ7dmFsdWUNVGhpcyByZXByZXNlbnRzIHRoZSBzYW1lIGNv
bmNlcHQgYXMNICAgIHBob3QuZmx1eDtpbnRlbnQuY2FsY3VsYXRlZDtlbS5vcHRpY2FsO3Zh
bHVlDUJ5IHNwZWNpZnlpbmcgdGhlIG9yZGVyIG9mIG1vZGlmaWVycyB1c2VycyBhcmUgYWJs
ZSB0byBtYXRjaCBVQ0RzIGJ5IHNpbXBsZSBzdHJpbmcgY29tcGFyaXNvbnMuICBBIGtleSBp
c3N1ZSB0byByZW1lbWJlciBpcyB0aGF0IG1vZGlmaWVycyBkbyBub3QgbW9kaWZ5IGVhY2gg
b3RoZXIsIGJ1dCB0aGUgYmFzZSBjb25jZXB0LiANT24gdGhlIG90aGVyIGhhbmQgdGhlIG9y
ZGVyIG9mIGF0dHJpYnV0ZXMgaXMgdmVyeSBzaWduaWZpY2FudCBhbmQgdW5jb25zdHJhaW5l
ZCBieSB0aGUgc3ludGF4LiAgIFRoZSBlcnJvciBpbiB0aGUgbWF4aW11bSBpcyBhIHZlcnkg
ZGlmZmVyZW50IHRoaW5nIHRoYW4gdGhlIG1heGltdW0gb2YgdGhlIGVycm9yLg0NVGhlIHR5
cGUgY2xhc3Mgb2YgYSBnaXZlbiB3b3JkdGVybSBpbiB0aGUgVUNEIHZvY2FidWxhcnkgY2Fu
IGJlIGluZmVycmVkIGZyb20gdGhlIGluaXRpYWwgYXRvbXdvcmQuICBXb3JkVGVybXMgYmVn
aW5uaW5nIHdpdGggZW0sIGZyYW1lLCBtZWFzLCAgb3IgaW50ZW50IGFyZSBtb2RpZmllcnMu
ICBUaGUgaW5pdGlhbCBhdG9td29yZCBzdGF0IG9yIGZpbHRlciBzaWduYWxzIGFuIGF0dHJp
YnV0ZS4gIFRoZSBzaW5nbGUgYXRvbXdvcmQgd29yZHRlcm1zIHZhbHVlLCB2ZWN0b3IsIGxv
Y2FsLCBpbnN0YW5jZSBhbmQgbXVsdGlwbGV0IGFyZSBzcGVjaWFsIGF0dHJpYnV0ZXMuICBB
bGwgb3RoZXIgd29yZHRlcm1zIGFyZSBiYXNlIGNvbmNlcHRzLg0NVGhlIG5lZWQgZm9yIHdl
bGwtZm9ybWVkIFVDRHMgIChvciBzb21lIGVxdWl2YWxlbnQpIGlzIG5lZWRlZCBpbiB0aGUg
b2xkIHByb3Bvc2FsIGFzIHdlbGwuICBJZiB3ZSBoYXZlIG1vcmUgdGhhbiBvbmUgbW9kaWZp
ZXIsIHRoZW4gdGhlIG1vZGlmaWVyIHByb3BlcnR5IChvciBjb25jZXB0LCBJkm0gbm90IHN1
cmUgd2hpY2ggaXMgYXBwcm9wcmlhdGUgaW4gdGhlIG9sZCBwcm9wb3NhbCkgdGhlbiB0aGVy
ZSBkb2VzbpJ0IHNlZW0gdG8gYmUgYW55IG5hdHVyYWwgd2F5IHRvIHNwZWNpZnkgdGhlIG9y
ZGVyIG9mIHRoZSBhdHRyaWJ1dGVzLiAgU2luY2UgdGhlIG9sZCBwcm9wb3NhbCBhbGxvd3Mg
YSBmYWlybHkgYXJiaXRyYXJ5IHNldCBvZiByZWxhdGVkIGNvbmNlcHRzIGFuZCBwcm9wZXJ0
aWVzIGluIHRoZSBVQ0QgYXNzZXNzaW5nIHRoZSCRZXF1YWxpdHmSIG9mIHR3byBVQ0RzIHdv
dWxkIGJlIGV4dHJlbWVseSBkaWZmaWN1bHQuICANSG93ZXZlciB0aGUgcmVxdWlyZW1lbnQg
dGhhdCB0aGUgVUNEIGVuZCBpbiBhbiBhdHRyaWJ1dGUgcHJvcGVydHkgaXMgcmVxdWlyZWQg
YnkgdGhpcyBuZXcgc2NoZW1lIHRvIGVuc3VyZSB0aGF0IHJlZ3VsYXIgZXhwcmVzc2lvbiBt
YXRjaGVzIG9mIHRoZSB0eXBlIHRoYXQgQWxhZGluIGN1cnJlbnRseSBkb2VzIGNhbiBiZSBk
b25lIHdpdGggZ29vZCByZWxpYWJpbGl0eS4NDTQuMS4yIE5hbWVzcGFjZXMuDVRoZSB1c2Ug
b2YgbmFtZXNwYWNlcywgaW5kaWNhdGVkIGJ5IHRoZSBwcmVzZW5jZSBvZiBhIGNvbG9uIGlu
IHRoZSB3b3JkIGlzIHBvc3NpYmxlLCBidXQgc2hvdWxkIGJlIGF2b2lkZWQgYXMgZmFyIGFz
IHBvc3NpYmxlLiBUaGUgbmFtZXNwYWNlIGlzIGRlZmluZWQgYnkgdGhlIHN0cmluZyBiZWZv
cmUgdGhlIGNvbG9uIGFuZCB0aGUgd29yZCBmb2xsb3dzLiAgVGhlIHdvcmRzIGluIHRoZSBu
b24tc3RhbmRhcmQgbmFtZXNwYWNlIG11c3QgYmUgZGlzdGluY3QgZnJvbSBhbGwgd29yZHMg
Y3VycmVudGx5IGluIHRoZSBJVk9BIG5hbWVzcGFjZS4gIA1XaGlsZSBkZXZlbG9wZXJzIG1h
eSBuZWVkIGxvY2FsIG5hbWVzcGFjZSwgdGhleSBzaG91bGQgYmUgdXNlZCBvbmx5IHRlbXBv
cmFyaWx5LCBmb3Igd29yZHMgdGhhdCBhcmUgbm90IHlldCBpbmNsdWRlZCBpbnRvIHRoZSBV
Q0QgdmFsaWRhdGVkIGJ5IHRoZSBJVk9BLiAgTmV3IHdvcmRzIHNob3VsZCBiZSBhZGRlZCB1
c2luZyB0aGUgcHJvY2VkdXJlcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiBYWC4NIA00LjEuMyBF
eGFtcGxlcyBvZiBMZWdhbCBTeW50YXgNVGhlIGZvbGxvd2luZyBleGFtcGxlcyBoYXZlIGxl
Z2FsIFVDRCBzeW50YXg6DXBvcy5lcS5yYTt2YWx1ZQ1wb3MuZXEucmE7bWVhcy5lcnJvcg1p
dm9hOm1ldGEuaWQ7dmFsdWUNbWV0YS5pZDt2YWx1ZQ1NZXRhLklEO1ZhbHVlDXgxOmV4cGVy
aW1lbnRhbC5xdWFudGl0eTt4MjpuZXcubW9kaWZpZXI7c3RhdC5lcnJvcm1heA1JbiB0aGlz
IGxpc3QsIDMgLDQgYW5kIDUgYXJlIGFsbCAgZXF1aXZhbGVudCBiZWN1YXNlIGl2b2E6IGlz
IHRoZSBkZWZhdWx0IG5hbWVzcGFjZSBhbmQgVUNEcyBhcmUgY2FzZSBpbnNlbnNpdGl2ZS4g
IE5vdGUgdGhhdCB0aGUgbmFtZXNwYWNlIGFwcGxpZXMgc2VwYXJhdGVseSB0byBlYWNoIHdv
cmQgaW4gdGhlIFVDRC4gVGh1cyBleGFtcGxlIDYgaGFzIHdvcmRzIGZyb20gdHdvIG5vbi1z
dGFuZGFyZCBuYW1lc3BhY2VzIGFuZCBvbmUgZnJvbSB0aGUgc3RhbmRhcmQgbmFtZXNwYWNl
Lg00LjEuNCBFeGFtcGxlcyBvZiBJbGxlZ2FsIFN5bnRheA1UaGUgZm9sbG93aW5nIFVDRHMg
YXJlIGludmFsaWQuICBUaGUgdGFibGUgaW5kaWNhdGVzIHRoZSByZWFzb24uDQ1wb3MuZXEu
cmE7IHZhbHVlICAgICAgICAgICAgICAJRW1iZWRkZWQgc3BhY2UNcG9zLmVxLnJhOzttZWFz
LmVycm9yCSAgIAlOdWxsIHdvcmR0ZXJtDXBvcy4uZXEucmE7bWVhcy5lcnJvcgkJTnVsbCBh
dG9td29yZA1waG90LmZsdXg7eDE6bWVhcy5lcnJvcgkJTmFtZXNwYWNlIHJldXNlcyBleGlz
dGluZyB3b3JkdGVybQ1NZWFzLkVycm9yCQkJCU5vIGJhc2UgY29uY2VwdA1NYXRoLnJhdGlv
O1Bob3QuZmx1eDtUaW1lLmV4cG9zdXJlDQkJCQkJCUJhc2UgY29uY2VwdHMgdXNlZCBhZnRl
ciBmaXJzdCB3b3JkdGVybQ0JCQkJCQlHcm91cGluZyBjb25zdHJ1Y3RzIChzZWN0aW9uIDUp
IHdvdWxkDQkJCQkJCWJlIHVzZWQgdG8gYXNzb2NpYXRlIGNvbHVtbmNvbnRlbnRzLg03CVBo
b3QuZmx1eDtlbS5wb2xhcml6ZWQJCURvZXMgbm90IHRlcm1pbmF0ZSBpbiBhbiBhdHRyaWJ1
dGUNOCAgUGhvdC5mbHV4O2ludGVudC5jYWxjdWxhdGVkO2VtLnhyYXk7bWVhcy5lcnJvcg0J
CQkJCQlNb2RpZmllcnMgbm90IGluIGFscGhhYmV0aWNhbCBvcmRlci4NOSAgRmx1eDttZWFz
LmVycm9yO2VtLm9wdGljYWw7c3RhdC5tYXgNCQkJCQkJTW9kaWZpZXIgYXBwZWFycyBhZnRl
ciBhbiBhdHRyaWJ1dGUNIA00LjEuNSBCYWNrdXMtTmF1ciBGb3JtDTxhbHBoYT4gCQk6Oj0g
IGF8YnxjfGR8ZXxmfGd8aHxpfGp8a3xsfG18bnxvfHB8cXxyfHN8dHx1fHZ8d3x4fHl8eg0g
ICAgICAgICAgICAJICAgICAgICAgICB8QXxCfEN8RHxFfEZ8R3xIfEl8SnxLfEx8TXxOfE98
UHxRfFJ8U3xUfFV8VnxXfFh8WXxaDTxkaWdpdD4gCQk6Oj0gIDB8MXwyfDN8NHw1fDZ8N3w4
fDkNPGNoYXI+ICAJCTo6PSAgPGFscGhhPnw8ZGlnaXQ+fC0NPHBlcmlvZD4gCQk6Oj09IC4N
PHNlbWljb2xvbj4gCQk6Oj09IDsNPGNvbG9uPiAJCTo6PT0gOg08d29yZC1jb21wb25lbnR3
b3JkPiAJOjo9ICA8YWxwaGE+fDxkaWdpdD58PHdvcmQtY29tcG9uZW50d29yZD48Y2hhcj4N
PG5hbWVzcGFjZS1yZWY+IAk6Oj0gIDx3b3JkLWNvbXBvbmVudHdvcmQ+DTx3b3JkdGVybT4g
CQk6Oj0gPHdvcmQtY29tcG9uZW50d29yZD58PHdvcmR0ZXJtPiA8cGVyaW9kPiA8d29yZC1j
b21wb25lbnR3b3JkPg08bndvcmR0ZXJtPiAJCTo6PSA8bmFtZXNwYWNlLXJlZj4gPGNvbG9u
PiA8d29yZHRlcm0+IHwgPHdvcmR0ZXJtPg08QmFzZUNvbmNlcHQ+IAk6Oj0gPG53b3JkdGVy
bT4NPE1vZGlmaWVycz4JCTo6PSANICAgICAgICAgICAgICAgICAgICAgICAgPG53b3JkdGVy
bT47PE1vZGlmaWVycz4NPEF0dHJidXRlcz4gICAgICAgICA6Oj0gPG53b3JkdGVybT4NICAg
ICAgICAgICAgICAgICAgICAgICAgPG53b3JkdGVybT47PEF0dHJpYnV0ZXM+DTxVQ0Q+IAkJ
CTo6PSA8QmFzZUNvbmNlcHQ+ICAgICAgIyBTcGVjaWFsIGNhc2UgZm9yIGRlZmF1bHRpbmcg
dmFsdWUNICAgICAgICAgIAkJICAgIDxCYXNlQ29uY2VwdD47PE1vZGlmaWVycz48QXR0cmli
dXRlcz4NDUEgVUNEIGlzIGFsd2F5cyBjYXNlLWluc2Vuc2l0aXZlDQ00LjIgVUNEIFZvY2Fi
dWxhcnkNVGhpcyBhbmQgZm9sbG93aW5nIHN1YnNlY3Rpb25zIGRlc2NyaWJlIHRoZSB0aHJl
ZSBraW5kcyBvZiB3b3JkdGVybSB1c2VkIHdpdGhpbiBVQ0RzLiAgV29yZFRlcm1zIGJlbG9u
ZyB0byBvbmx5IG9uZSBvZiB0aGUgdGhyZWUgdHlwZXMuICBGb3IgZWFjaCBzZWN0aW9uIHRo
ZSBpbml0aWFsIGF0b213b3JkIG9mIGFwcHJvcHJpYXRlIHRyZWVzIGFuZCBhIGZldyBleGFt
cGxlIHdvcmR0ZXJtcyBhcmUgZ2l2ZW4uIFdoaWxlIGFkZGl0aW9uYWwgdHJlZXMgd2lsbCBk
b3VidGxlc3MgYmUgZGV2ZWxvcGVkLCByZS11c2Ugb2YgdGhlIGV4aXN0aW5nIGhpZXJhcmNo
aWVzIGlzIGVuY291cmFnZWQuIA00LjIuMSBCYXNlIENvbmNlcHRzLg1UaGlzIHNlY3Rpb24g
ZGlzY3Vzc2VzIGJhc2UgY29uY2VwdHMgb25lIG9mIHdoaWNoIHN0YXJ0cyBlYWNoIFVDRC4g
IC4gDWFyaXRoIAdxdWFudGl0aWVzIHJlbGF0ZWQgdG8gYXJpdGhtZXRpYyBhbmQgbWF0aGVt
YXRpY3MsIGluY2x1ZGluZyBjb3VudCwgZGlmZmVyZW5jZSwgcmF0aW8uICBTZWUgdGhlIGRp
c2N1c3Npb24gaW4gdGhlIGF0dHJpYnV0ZSBmaWx0ZXIuICBVc2Ugb2YgdGhlIGFyaXRoIHRy
ZWUgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgdG8gY2FzZXMgd2hlbiB0aGVyZSBpcyBubyBleGlz
dGluZyBVQ0QgdGhhdCBkZXNjcmliZXMgdGhlIGtpbmQgb2Ygcm93IGNvbnRlbnQgY3JlYXRl
ZC4gIEUuZy4sIGZvciBhIHRhYmxlIG9mIFgtcmF5IHNvdXJjZXMgd2l0aCBhIGNvdW50cyBh
bmQgZXhwb3N1cmUgY29sdW1uLCB0aGUgcHJvcGVyIGNvbHVtbiBmb3IgdGhlIHJhdGlvIG9m
IHRoZXNlIHR3byBjb2x1bW5zIGlzIGFsbW9zdCBjZXJ0YWlubHkgaW4gdGhlIHBob3QuZmx1
eCB0cmVlIHJhdGhlciB0aGFuIGFyaXRoLnJhdGlvLgcHY29uY2VwdAdUaGlzIHNpbmdsZSB3
b3JkdGVybSBpcyB1c2VkIGFzIHRoZSBvcmlnaW4gb2YgdGhlIGNvbmNlcHQgdHJlZS4gIFdo
aWxlIGl0IGlzIHJhcmVseSBuZWVkZWQgdG8gYmUgdXNlZCBpbiBVQ0RzIGl0IGNhbiBiZSB1
c2VkIHRvIGFmZmlybWF0aXZlbHkgZGVjbGFyZSB0aGF0IHRoZSB0YWJsZSB3cml0ZXIgZG9l
c26SdCBrbm93IG9yIGRvZXMgbm90IHdpc2ggdG8gcHVibGlzaCBhbnkgc2VtYW50aWMgaW5m
b3JtYXRpb24gYWJvdXQgdGhpcyBlbnRpdHkuICBUaGlzIGhhcyBtdWNoIHRoZSBzYW1lIGVm
ZmVjdCBhcyBub3QgaW5jbHVkaW5nIHRoZSBVQ0QgYXR0cmlidXRlLCBidXQgaWYgb25lIGlz
IGxvb2tpbmcgZm9yIGNvbHVtbmNvbnRlbnRzIHdpdGggdW5kZWZpbmVkIFVDRHMgaXQgbWF5
IGJlIGVhc2llciB0byBzZWFyY2ggZm9yIHRoZSBwYXJ0aWN1bGFyIHN0cmluZyBVQ0Q9Y29u
Y2VwdCB0aGFuIHRvIGZpbmQgdGhlIGxvY2F0aW9ucyB3aGVyZSBVQ0QgaXMgb21pdHRlZC4g
ICBJdCBjYW4gYWxzbyBiZSB1c2VkIGluIFVDRCB0ZW1wbGF0ZXMgd2hlcmUgaXQgbWlnaHQg
YmUgcmVwbGFjZWQgYnkgYSBiYXNlIGNvbmNlcHQgZnJvbSBhbnkgdHJlZSwgb3IgaW4gc2l0
dWF0aW9ucyB3aGVyZSBubyBzaW5nbGUgdHJlZSBpcyBhcHByb3ByaWF0ZS4gBwdodW1hbgdx
dWFudGl0aWVzIHJlbGF0ZWQgdG8gcGVvcGxlIGFuZCBpbnN0aXR1dGlvbnM6IG5hbWVzLCBh
ZGRyZXNzZXMsIHBob25lIG51bWJlcnMsbmF0aW9uYWxpdGllcy4HB21ldGEHcXVhbnRpdGll
cyByZWxhdGVkIHRvIG1ldGFkYXRhLCBzdWNoIGFzIElWTyBzdHlsZSBpZGVudGlmaWVycywg
ZmxhZ3MsIG5vdGVzLCBVUkwHB2luc3RyIAdxdWFudGl0aWVzIHJlbGF0ZWQgdG8gYW4gaW5z
dHJ1bWVudDsgdHlwaWNhbCBzdWItbGV2ZWxzIGFyZSB0ZWxlc2NvcGUsIG9ic2VydmF0b3J5
LCBldGMuBwdvYnMgB29ic2VydmF0aW9uIG1ldGhvZHMgc3VjaCBhcyBkZXRlY3RvciwgZmls
dGVyLCBwbGF0ZSwgc3BlY3Ryb2dyYXBoLCBleHBvc3VyZSB0aW1lLCBldGMuBwdwaG90IAdB
bGwgcGhvdG9tZXRyaWMgbWVhc3VyZW1lbnRzLCBvcmdhbml6ZWQgYWNjb3JkaW5nIHRvIHRo
ZSB3YXZlbGVuZ3RoOyBpbmNsdWRlcyBwb2xhcml6YXRpb24uDUmSbSBhIGxpdHRsZSBjb25m
dXNlZCBieSBwaHJhc2UgkWFjY29yZGluZyB0byB3YXZlbGVuZ3RokiB0aGF0IEmSdmUgcmV0
YWluZWQgYWJvdmUuDUlzICB0aGUgZW0gYnJlYWtkb3duIHdoaWNoIHVzZWQgdG8gYmUgaW5j
bHVkZWQgaW5zaWRlIHRoZSBwaG90IHN0dWZmIG5vdyBtb3ZlZCBlbnRpcmVseSB0byB0aGUg
ZW0gaGllcmFyY2h5LiAgSZJtIGFzc3VtaW5nIHRoYXQgd2UgdXNlIHBob3QuZmx1eDtlbS5v
cHRpY2FsLnUgcmF0aGVyIHRoYW4gcGhvdC5mbHV4Lm9wdGljYWwsICBJZiBzbyB3ZSBuZWVk
IHRvIGNoYW5nZSB0aGUgYWJvdmUuBwdwaHlzIAdHZW5lcmljIHBoeXNpY2FsIHF1YW50aXRp
ZXMsIHN1Y2ggYXMgbGVuZ3RoLCB2ZWxvY2l0eSwgbWFzcywgYW5kIGluY2x1ZGluZyBhdG9t
aWMgJiBtb2xlY3VsYXIgY29uY2VwdHMgYW5kIHByb3BlcnRpZXMsIHRlbXBlcmF0dXJlLCBw
cmVzc3VyZSwgZ3Jhdml0eSwgZXRjLi4uBwdwb3MgB1Bvc2l0aW9uIGluIHRoZSBza3ksIHJl
ZmVyZW5jZSBmcmFtZXM7IGluY2x1ZGluZyBlcXVhdG9yaWFsLCBnYWxhY3RpYyBldGMgY29v
cmRpbmF0ZXM7IGdlb2NlbnRyaWMsIGhlbGlvY2VudHJpYyBldGM7IGFuZCBwcmVjZXNzaW9u
IGFuZCBudXRhdGlvbi4gQWxzbyBpbmNsdWRlcyBwb3NpdGlvbiBvbiB0aGUgc3VyZmFjZSBv
ZiB0aGUgRWFydGguBwdzb2Z0B1NvZnR3YXJlIGRlZmluZWQgb2JqZWN0cywgZS5nLiwgc2Vy
dmljZXMsIGFyY2hpdmVzLCBjYXRhbG9ncwcHc3BlYyAHUXVhbnRpdGllcyByZWxhdGVkIHRv
IHNwZWN0cm9zY29waWMgbWVhc3VyZW1lbnRzBwdzcmMgB3Byb3BlcnRpZXMgb2YgdGhlIG9i
c2VydmVkIHNvdXJjZSBvZiByYWRpYXRpb246ICBjb21tb24gaWRzLCBzb3VyY2UgY2xhc3Np
ZmljYXRpb25zIGFuZCBtb3JwaG9sb2d5LCBleHRlbnNpb24gaW4gdGhlIHNreSwgdmFyaWFi
aWxpdHksIAcHdGltZQdRdWFudGl0aWVzIHJlbGF0ZWQgdG8gdGltZS4HB1RoZSBuZXcgdHJl
ZSB3YXMgc2ltcGxpZmllZCBjb21wYXJlZCB0byB0aGUgE0hZUEVSTElOSyAiLi4vLi4vLi4v
Li4vVUNEL1VDRC9qcy8iARRvbGQgVUNEIHRyZWUVOyBpbXBvcnRhbnQgbW9kaWZpY2F0aW9u
cyBpbmNsdWRlOiANQXRvbWljIGFuZCBtb2xlY3VsYXIgZGF0YSBhcmUgbW92ZWQgdG8gYSBi
cmFuY2ggb2YgcGh5cyANVGhlIHNyYyBicmFuY2ggaXMgaW50cm9kdWNlZCBmb3IgcGhvdG9u
IHNvdXJjZXMgc3VjaCBhcyBzdGFycywgZ2FsYXhpZXMgZXRjLg1PYnNlcnZhdG9yeSBpbmZv
cm1hdGlvbiBpcyBtb3ZlZCB0byB0aGUgaW5zdHIgYnJhbmNoLg1BIGh1bWFuIHRyZWUgaXMg
YWRkZWQgdG8gaG9sZCBjb25jZXB0cyByZWxhdGluZyB0byB0aGUgcGVvcGxlIGFuZCBpbnN0
aXR1dGlvbnMNQSBzb2Z0IHRyZWUgaXMgYWRkZWQgdG8gaG9sZCBjb25jZXB0cyByZWxhdGlu
ZyB0byBzb2Z0d2FyZSBlbnRpdGllcyB0aGF0IG1heSBiZSBkZXNjcmliZWQgaW4gVk8gZW50
aXRpZXMuDVRoZSBzaW5nbGUgd29yZCBjb25jZXB0IGlzIGFkZGVkIHRvIGJlIHRoZSByb290
IG9mIGFsbCBjb25jZXB0cy4NTW9yZSBkZXRhaWxzIGFib3V0IHNvbWUgb2YgdGhlIG1vc3Qg
aW1wb3J0YW50IGJyYW5jaGVzIGFyZSBzaG93biBpbiB0aGUgE0hZUEVSTElOSyAiIiBcbCAi
VUNEdHJlZSIBFGFubmV4FSBiZWxvdy4gDQ00LjIuMiBNb2RpZmllcnMgcHJvcGVydGllcy4N
VGhlc2Ugd29yZHRlcm1zIGFyZSB1c2VkIHRvIG1vZGlmeSB0aGUgbWVhbmluZyBvZiBhIGJh
c2UgY29uY2VwdC4gIENoYW5nZXMgYW5kIGFkZGl0aW9ucyB0byB0aGUgbW9kaWZpZXIgdHJl
ZSBzaG91bGQgYmUgbWFkZSB3aXRoIHNvbWV3aGF0IGdyZWF0ZXIgY2FyZSB0aGFuIGZvciBi
YXNlIGNvbmNlcHRzLiAgVXNlcnMgc2hvdWxkIGNhcmVmdWxseSBjb25zaWRlciBob3cgdGhl
IG1vZGlmaWVyIHdvcmtzIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGFsbCBiYXNlIGNvbmNl
cHRzLiAgTW9kaWZpZXJzIHNob3VsZCBiZSBjYXJlZnVsbHkgY2hvc2VuIHNvIGFzIG5vdCB0
byBpbnRyb2R1Y2UgYW1iaWd1aXRpZXMgaW4gdGhlIGZvcm11bGF0aW9uIG9mIFVDRHMuDQ1l
bSAHcXVhbnRpdGllcyB3aGljaCBkZXNjcmliZSB0aGUga2luZCBvZiBlbGVjdHJvbWFnbmV0
aWMgcmFkaWF0aW9uIGludm9sdmVkIGluIHRoZSBiYXNlIGNvbmNlcHQsIG5vdGFibGUgZnJl
cXVlbmN5L2VuZXJneS93YXZlbGVuZ3RoIGFuZCBwb2xhcml6YXRpb24uICBTaW5jZSBtYW55
IG9mIHRoZXNlIHNhbWUgcXVhbnRpdGllcyBhcHBseSB0byBncmF2aXRhdGlvbmFsIHJhZGlh
dGlvbiBhbmQgc29tZSB0byBwYXJ0aWNsZSBkZXRlY3Rpb25zLCB0aGUgZW0gYXRvbXdvcmQg
bWF5IGJlIGludGVycHJldGVkIGxvb3NlbHkgaW4gdGhlc2UgY2FzZXMuIAcHZnJhbWUHcXVh
bnRpdGllcyB3aGljaCBkZXNjcmliZSB0aGUgZnJhbWUgaW4gd2hpY2ggdGhlIGJhc2UgY29u
Y2VwdCBpcyB0byBiZSB0YWtlbiwgaS5lLiwgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIGJh
c2UgY29uY2VwdCBpcyByZWFsaXplZC4gIFRoZSBlbSBxdWFsaWZpZXIgYWRkcmVzc2VzIHRo
ZSBlbmVyZ3kgZGltZW5zaW9uIG9mIHRoZSBmcmFtZSBhbmQgdGhlIHNwYXRpYWwgZWxlbWVu
dCBpcyB0eXBpY2FsbHkgaW5jbHVkZWQgaW4gdGhlIGJhc2UgY29uY2VwdCAoY2YuIHRoZSBl
cSBhbmQgZ2FsIGZpZWxkcyBpbnNpZGUgcG9zKS4gIEhvd2V2ZXIgdGltZSBmcmFtZXMgc2hv
dWxkIGdlbmVyYWxseSBiZSBhZGRyZXNzZWQgaGVyZS4gIEUuZy4sIGEgVUNEIG1pZ2h0IGJl
IGRlZmluZWQgYXMgdGltZTtmcmFtZS50aW1lLmdlb2NlbnRyaWM7dmFsdWUuIFRoZSBmcmFt
ZSBhdHRyaWJ1dGUgbWlnaHQgYWxzbyBiZSB1c2VkIG1vZGlmeSBzcGF0aWFsIGNvb3JkaW5h
dGUgc3lzdGVtcyBhcyBpbjogcG9zLiBib2R5LmxhdDtmcmFtZS5ib2R5Lm1hcnM7dmFsdWUu
DUFsbW9zdCBhbGwgbW9kaWZpZXJzIGNhbiBiZSB0aG91Z2h0IG9mIGFzIGJlaW5nIGluIHRo
ZSBmcmFtZSB0cmVlLCBlLmcuLCB0aGUgZW0gYW5kIGludGVudCB0cmVlcyBjb3VsZCBlYXNp
bHkgYmUgcmVuZGVyZWQgYXMgZnJhbWUuZW0gYW5kIGZyYW1lLmh1bWFuaW50ZW50LCBidXQg
YXJlIHNlcGFyYXRlZCBvdXQgc2luY2UgdGhleSBhcmUgc28gY29tbW9uLiAgBwdpbnRlbnQH
cXVhbnRpdGllcyB0aGF0IHJlc3RyaWN0IHRoZSBodW1hbiBjb250ZXh0IG9mIHRoZSBjb25j
ZXB0LiAgRS5nLiwgY2FsY3VsYXRlZCwgcHJlZGljdGVkLCBzaW11bGF0ZWQuICBUaGlzIHNo
b3VsZCBub3QgYmUgdXNlZCB0byBkaXN0aW5ndWlzaCBhbW9uZyBkaXN0aW5jdCBzY2llbmNl
IGVsZW1lbnRzLCBlLmcuLCBiYWNrZ3JvdW5kIHZlcnN1cyBmb3JlZ3JvdW5kIHdoaWNoIHdv
dWxkIG5vcm1hbGx5IGJlIHBhcnQgb2YgdGhlIGJhc2UgY29uY2VwdCBvciB0aGUgbWVhc3Vy
ZW1lbnQgaWYgdGhleSBhcmUgYWRkcmVzc2VkIGF0IGFsbC4HBw1UaGUgbW9kaWZpZXJzIGlu
Y2x1ZGUgdHdvIG5ldyB0cmVlcywgZnJhbWUgYW5kIGludGVudCB3aGljaCBhcmUgZGlzY3Vz
c2VkIGFib3ZlLg0NNC4yLjMgQXR0cmlidXRlcyBwcm9wZXJ0aWVzLg1BdHRyaWJ1dGVzIHBy
b3BlcnRpZXMgaW5kaWNhdGUgdGhhdCB0aGUgZ2l2ZW4gVUNEIGxhYmVscyBhbiBhdHRyaWJ1
dGUgb2YgdGhlIGJhc2UgY29uY2VwdC4gIEUuZy4sIHRoZSB2YWx1ZSxtZWFzLmVycm9yLGFu
ZCBzdGF0Lm1heCBhdHRyaWJ1dGVzIGRlc2NyaWJlIGVudGl0aWVzIHRoYXQgZ2l2ZSB2YWx1
ZXMsIGVycm9ycyBhbmQgbWF4aW11bSBvZiB0aGUgYmFzZSBjb25jZXB0LiAgTm90ZSB0aGF0
IHRoZSBVQ0QgaW5kaWNhdGVzIGEgc2VtYW50aWMgcmVsYXRpb25zaGlwIGFuZCBub3QgbmVj
ZXNzYXJpbHkgYSBwaHlzaWNhbCByZWxhdGlvbnNoaXAuICBFLmcuLCBzdXBwb3NlIGEgdXNl
ciBzdWJtaXRzIGEgcmVxdWVzdCByZW5kZXJlZCBpbiBTUUwgYXMgk3NlbGVjdCBtYXgocmEp
IGZyb20gdGFibGWULiAgVGhpcyByZXR1cm4gZnJvbSB0aGlzIHF1ZXJ5IG1pZ2h0IGJlIGEg
c2luZ2xlIGNlbGwgdGFibGUgd2l0aCBhIFVDRCBmb3IgdGhlIGNvbHVtbiBhcyBwb3MuZXEu
cmE7c3RhdC5tYXggZXZlbiB0aG91Z2ggdGhlcmUgaXMgbm8gcmlnaHQgYXNjZW5zaW9uIGNv
bHVtbiBwcmVzZW50IGluIHRoZSB0YWJsZSB0aGUgdXNlciBzZWVzLg0NVGhpcyBkb2VzIG5v
dCBtZWFuIHRoYXQgYXR0cmlidXRlcyBwcm9wZXJ0aWVzIGNhbm5vdCBiZSB1c2VkIHRvIGRl
dGVybWluZSB0aGUgbGlrZWx5IHJlbGF0aW9uc2hpcHMgYW1vbmcgY29sdW1ucyBpbiBhIHRh
YmxlLiAgSG93IHRoaXMgaXMgZG9uZSBpcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiA1Lg1BcyB3
aXRoIG1vZGlmaWVycywgYXR0cmlidXRlcyBzaG91bGQgYmUgZXh0ZW5kZWQgd2l0aCBjb25z
aWRlcmFibGUgY2FyZS4gIEFkZGl0aW9ucyB0byB0aGUgc2luZ2xlIHdvcmQgYXR0cmlidXRl
cyBhcmUgc2hvdWxkIGJlIHBhcnRpY3VsYXJseSBzY3J1cHVsb3VzbHkgY29uc2lkZXJlZC4N
DVRoZSBmb2xsb3dpbmcgYXR0cmlidXRlIHRyZWVzIGFyZSBkZWZpbmVkLg0NZmlsdGVyB0Eg
ZmlsdGVyIGlzIGFuIGF0dHJpYnV0ZSB0aGF0IHJlZmxlY3RzIHByb2Nlc3Npbmcgb24gc29t
ZSBvdGhlciBjb2x1bW5jb250ZW50LiAgVGhlIGF0dHJpYnV0ZSB0cmVlcyBmb3IgZmlsdGVy
IGFuZCBzdGF0IGFuZCB0aGUgY29uY2VwdCB0cmVlIGZvciBhcml0aCBhcmUgbGlua2VkIGJ1
dCBkaXN0aW5jdC4gIA1Bcml0aCBzaG91bGQgbm9ybWFsbHkgYmUgcmVzZXJ2ZWQgZm9yIGNv
bmNlcHRzIHRoYXQgaW52b2x2ZSB0aGUgY29tYmluYXRpb24gb2YgbXVsdGlwbGUgY29sdW1u
Y29udGVudHMgc28gdGhhdCB0aGVyZSBpcyBubyBzaW5nbGUgYmFzZSBVQ0QuICBUaGUgYXNz
b2NpYXRpb24gb2YgYW4gYXJpdGggY29sdW1uY29udGVudCB3aXRoIHRoZSBjb2x1bW5jb250
ZW50cyBpdCBkZXJpdmVzIGZyb20gaXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNS4NU3RhdCBh
dHRyaWJ1dGVzIHJlZmVyIHRvIHByb2Nlc3Npbmcgb2Ygc2luZ2xlIGNvbHVtbmNvbmNlcHQg
Y29udGVudHMgdGhhdCBub3JtYWxseSByZWR1Y2VzIHRoZSBkaW1lbnNpb25hbGl0eSBvZiB0
aGUgZGF0YSAoZS5nLiwgYSBkYXRhIGNvbHVtbiBhcnJheSBpcyB0cmFuc2Zvcm1lZCBpbnRv
IHNvbWUgc3RhdGlzdGljIG9uIHRoZSBjb2x1bW5jb250ZW50KS4gIFRoZXJlIHdpbGwgbm9y
bWFsbHkgYmUgYSBzaW5nbGUgdmFsdWUgb2Ygc3RhdC5tYXggYXNzb2NpYXRlZCB3aXRoIGFs
bCBvZiB0aGUgdmFsdWVzIGluIGEgY29sdW1uYXJyYXkuICBUaHVzIGZvciBzaW1wbGUgVk9U
YWJsZXMgdGhlIHN0YXQgYXR0cmlidXRlcyBtYXkgb2Z0ZW4gYmUgZm91bmQgaW4gUEFSQU1F
VEVSIGVsZW1lbnRzIHJhdGhlciB0aGFuIEZJRUxEIGVsZW1lbnRzLiAgSG93ZXZlciBpZiBh
IGNvbHVtbiBoYXMgdmVjdG9yIHZhbHVlZCBjZWxscywgdGhlbiB0aGVyZSBtYXkgYmUgYSBz
dGF0Lm1heCBhdHRyaWJ1dGUgYXNzb2NpYXRlZCB3aXRoIGVhY2ggcm93IJYgYnV0IGl0IHdp
bGwgYmUgYSBzY2FsYXIuICBPY2Nhc2lvbmFsbHkgc3RhdCBxdWFudGl0aWVzIG1heSBoYXZl
IHRoZSBzYW1lIGRpbWVuc2lvbmFsaXR5IGluIHRoZSB0YWJsZSBhcyB0aGUgYmFzZSBjb25j
ZXB0LCBidXQgZXZlbiB0aGlzIHdpbGwgb2Z0ZW4gcmVmbGVjdCB0aGUgZmFjdCB0aGF0IHRo
ZSBtYXggY29sdW1uIHBvaW50ZWQgdG8gYW4gYXJyYXkgb2YgZGF0YSB0aGF0IGhhcyBub3Qg
YmVlbiByZWNvcmRlZC4gIEUuZy4sIHdlIG1pZ2h0IHJlY29yZCB0aGUgdGVtcGVyYXR1cmUg
b2YgYW5pbnN0cnVtZW50IGF0IHRoZSBiZWdpbm5pbmcgb2YgZWFjaCBtaW51dGUgYXMgd2Vs
bCBhcyB0aGUgbWF4aW11bSBhbmQgbWluaW11bSB0ZW1wZXJhdHVyZXMgZHVyaW5nIHRoZSBt
aW51dGUuICBUaGUgdmFsdWUgYW5kIHN0YXQubWF4IGNvbHVtbmNvbnRlbnRzIGhhdmUgdGhl
IHNhbWUgZGltZW5zaW9uYWxpdHksIGJ1dCB0aGUgbWF4aW11bSB3YXMgZGVyaXZlZCBmcm9t
IGEgaGlnaGVyIGRpbWVuc2lvbmFsaXR5IGRhdGFzZXQuDVRoZSBmaWx0ZXIgdHJlZSByZWZs
ZWN0cyBwcm9jZXNzaW5nIG9mIGEgc2luZ2xlIGNvbHVtbmNvbmNlcHQgY29udGVudCB0aGF0
IHByZXNlcnZlcyBpdHMgZGltZW5zaW9uYWxpdHkuICBGaWx0ZXJzIG1heSBiZSBjb21tb24g
Zm9yIHZlY3Rvcm1hcCBvciBpbWFnZSBjb2x1bW5jb250ZW50cy4gIEF0dHJpYnV0ZXMgd291
bGQgaW5jbHVkZTogc21vb3RoLCBjb21wcmVzcywgcm90YXRlLgcHbWVhcyAHQSBtZWFzIGlz
IGFuIGFBdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgcHJvY2VzcyBvZiBtZWFzdXJl
bWVudC4gIFRoZSBhdHRyaWJ1dGUgbWVhcy52YWx1ZSBzaG91bGQgbm90IGJlIHVzZWQgKHVz
ZSBqdXN0IHZhbHVlIGluc3RlYWQpLiAgRXJyb3IsIGVycm9yLnN0YXRpc3RpY2FsLCBhbmQg
ZXJyb3Iuc3lzdGVtYXRpYyBhcmUga2V5IG1lbWJlcnMgb2YgdGhpcyB0cmVlLiANU2VlIHRo
ZSBkaXNjdXNzaW9uIGZvciBmaWx0ZXIgdG8gdW5kZXJzdGFuZCB3aHkgZXJyb3Igd2FzIHRh
a2VuIG91dCBvZiB0aGUgc3RhdCB0cmVlLCBpLmUuLCBlcnJvciBoYXMgdGhlIHNhbWUgZGlt
ZW5zaW9uYWxpdHkgYXMgdmFsdWUuICBJdCBhbHNvIGRvZXNuknQgcmVhbGx5IGZpdCBzZW1h
bnRpY2FsbHkgaW50byBzdGF0LgcHc3RhdAdBIHN0YXQgaXMgYW4gYUF0dHJpYnV0ZXMgdGhh
dCByZWZsZWN0IHRoZSBjYWxjdWxhdGlvbiBvZiBhIHN0YXRpc3RpYyBvbiBhIGNvbGxlY3Rp
b24gb2YgZWxlbWVudHMgZGVzY3JpYmVkIGluIHRoZSBiYXNlIGNvbmNlcHQuICBXaGVyZSBh
cHByb3ByaWF0ZSBhdHRyaWJ1dGVzIGxpa2Ugc3RhdC5tYXggbWF5IGJlIHVzZWQgaW4gYWxw
aGFudW1lcmljIGFzIHdlbGwgYXMgbnVtZXJpY2FsIGNvbnRleHRzLCBidXQgbWFueSBzdGF0
IGVsZW1lbnRzIGFyZSB1c2VmdWwgb25seSBpbiBudW1lcmljYWwgY29udGV4dHMuICBTZWUg
dGhlIGRpc2N1c3Npb24gaW4gZmlsdGVyIGFib3ZlLgcHDVRoZSBmaWx0ZXIgYW5kIG1lYXMg
dHJlZXMgYXJlIG5ldy4gDVRoZXJlIGFyZSBhIGZldyBuZXcgc3BlY2lhbCBzaW5nbGUgd29y
ZCBhdHRyaWJ1dGVzIHdoaWNoIHdlIG5vdyBkaXNjdXNzLiAgVGhlc2UgYXR0cmlidXRlcyBw
bGF5IGEgY2VudHJhbCByb2xlIGluIGJ1aWxkaW5nIGNvbXBsZXggVUNEcy4gDXZhbHVlB1Ro
ZSB2YWx1ZSBhdHRyaWJ1dGUgaXMgdGhlIGJhc2ljIGF0dHJpYnV0ZSBmb3Igc2ltcGxlIGNv
bmNlcHRzLiAgSXQgcmVwcmVzZW50cyB0aGUgYWN0dWFsIGluc3RhbnRpYXRpb24gb2YgdGhl
IHN0cmluZyBvciBudW1iZXIgdGhhdCBpcyBpbXBsaWVkIGJ5IHRoZSBjb25jZXB0LiAgQSB2
YWx1ZSBhdHRyaWJ1dGUgc2hvdWxkIG5ldmVyIGJlIHVzZWQgYWZ0ZXIgYW5vdGhlciBhdHRy
aWJ1dGUuICBJLmUuLCBwaG90LmZsdXg7bWVhcy5lcnJvcjt2YWx1ZS5pcyBpbmNvcnJlY3Q6
IHRoZSB2YWx1ZSBpcyBzdXBlcmZsdW91cy4gICBOb3RlIHRoYXQgaWYgdGhlIGJhc2ljIGNv
bmNlcHQgaXMgdmVjdG9yLXZhbHVlZCwgdGhlIHZhbHVlIG1heSBiZSBhIHZlY3Rvci4gIEku
ZS4sIGNvbnNpZGVyIGNlbGwgdGhhdCBjb250YWlucyBhbiBhcnJheSBvZiBmbHV4ZXMuICBT
aW5jZSBVQ0RzIGFyZSBpbnRlbmRlZCB0byBjb252ZXkgdGhlIHNlbWFudGljIGNvbnRlbnQg
b2YgdGhlIGNlbGwsIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGRpc3Rpbmd1aXNoIHdo
ZXRoZXIgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBjZWxsIHdhcyBhIHRpbWUgc2VyaWVzIG9y
IGEgc3BlY3RydW0uICBJZiB3ZSBkZWZpbmUgYXBwcm9wcmlhdGUgVUNEcyBwaG90LnNwZWN0
cnVtO2VtLm9wdGljYWw7dmFsdWUgYW5kIHBob3QudGltZXNlcmllcztlbS5vcHRpY2FsO3Zh
bHVlIHdlIGNhbiBkaXN0aW5ndWlzaCB0aGVzZSB0d28gc2l0dWF0aW9ucy4gBwd2ZWN0b3IH
VGhpcyBhdHRyaWJ1dGUgbWF5IGJlIHVzZWQgd2hlbiB0aGVyZSBpcyBubyBzcGVjaWFsIFVD
RCBkZXNjcmliaW5nIGFuIGFycmF5IG9mIHRoZSBiYXNlIGNvbmNlcHQuICBXaGlsZSBWT1Rh
YmxlcyBwcm92aWRlIGEgZGltZW5zaW9uIGF0dHJpYnV0ZSwgaXQgc2VlbXMgbGlrZWx5IHRo
YXQgdXNlcnMgd2lsbCBmaW5kIGJlaW5nIGFibGUgdG8gZGlzdGluZ3Vpc2ggdmVjdG9yIGFu
ZCBzY2FsYXIgY29sdW1ucyBpbiB0aGUgVUNEIHVzZWZ1bC4gIEVycm9ycyBhbmQgZmlsdGVy
cyBhc3NvY2lhdGVkIHdpdGggdmVjdG9yIHF1YW50aXRpZXMgd291bGQgYWxzbyBsaWtlbHkg
YmUgdmVjdG9ycy4gIE5vdGUgdGhhdCBzb21lIFVDRHMgc2hvdWxkIGltcGx5IGEgdmVjdG9y
IGNvbHVtbmNvbnRlbnQuICBFLmcuLCBhIHBob3Quc3BlY3RydW0gb3IgcGhvdC50aW1lc2Vy
aWVzIG1pZ2h0IGJlIHVzZWQgdG8gZGVzY3JpYmUgYSBjZWxsIHdpdGggYW4gYXJyYXkgb2Yg
Zmx1eCB2YWx1ZXMuICBUaGUgVUNEIHBob3Quc3BlY3RydW07dmVjdG9yIHdvdWxkIGltcGx5
IGEgdmVjdG9yIG9mIHNwZWN0cmEgaW4gZWFjaCBjZWxsLgcHaW5zdGFuY2UHVGhpcyBwbGF5
IHRoZSByb2xlIG9mIHZhbHVlIGZvciBjb21wbGV4IFVDRHMsIGkuZS4sIHRoZSBVQ0RzIG9m
IHRhYmxlcyBhbmQgZ3JvdXBzLiBJdCBpbmRpY2F0ZXMgdGhhdCBhbGwgb2YgdGhlIGZpZWxk
cyBhbmQgcGFyYW1ldGVycyBpbiB0aGUgYXBwcm9wcmlhdGUgc2NvcGUgYXJlIGF0dHJpYnV0
ZXMgb2YgdGhlIGNvbmNlcHQgZGVzY3JpYmVkIGluIHRoaXMgVUNELiAgRS5nLiwgYSBzaW1w
bGUgdGFibGUgVUNEIG1pZ2h0IGJlIHNyYztpbnN0YW5jZS4gIFRoZSBpbnN0YW5jZSBpbmRp
Y2F0ZXMgdGhhdCBpbiBlYWNoIHJvdyB0aGUgcmEsIGRlYywgZmx1eCwgbmFtZSwgZXRjLiBy
ZWZlciB0byBhIHNpbmdsZSBwYXJ0aWN1bGFyIHNvdXJjZS4HB211bHRpcGxldAdUaGlzIGNh
biBiZSB1c2VkIGluc3RlYWQgb2YgaW5zdGFuY2UgaW4gY29tcGxleCBVQ0RzIHRvIGluZGlj
YXRlIHRoYXQgdGhlcmUgYXJlIHNldmVyYWwgb2YgdGhlIHNhbWUgaW5zdGFuY2VzIGluIGVh
Y2ggcm93IG9mIHRoZSB0YWJsZS4gIFRoaXMgYXR0cmlidXRlIHNob3VsZCByYXJlbHkgYmUg
dXNlZCwgYnV0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIGluIGEgY29udGV4dCB3aGVyZSB0d28g
dGFibGVzIGhhdmUgYmVlbiBjcm9zcy1jb3JyZWxhdGVkIGFuZCBuZWl0aGVyIHRhYmxlIGlz
IGNvbnNpZGVyZWQgc3Vib3JkaW5hdGUgdG8gdGhlIG90aGVyLiAgRS5nLiwgYWZ0ZXIgY3Jv
c3MtY29ycmVsYXRpbmcgdGhlIFJPU0FUIGFuZCBBU0NBIG9ic2VydmF0aW9ucyBvdmVyIHRo
ZSBza3ksIHRoZSByZXN1bHQgaXMgYSB0YWJsZSBlYWNoIHJvdyBvZiB3aGljaCByZXByZXNl
bnRzIGEgcGFpciBvZiBvYnNlcnZhdGlvbnMuBwdsb2NhbAdUaGlzIHNwZWNpYWwgYXR0cmli
dXRlIGFzc2VydHMgdGhhdCB0aGUgc2VtYW50aWNzIG9mIHRoZSBjb2x1bW5jb250ZW50IGFy
ZSBzdWNoIHRoYXQgaXQgY2Fubm90IGJlIHVzZWQgb3V0c2lkZSBvZiBpdHMgbG9jYWwgY29u
dGV4dC4gIEluIHBhcnRpY3VsYXIgaXQgaW5kaWNhdGVzIHRoYXQgdGhpcyBjb2x1bW5jb250
ZW50IHNob3VsZCBub3QgYmUgY3Jvc3MtY29ycmVsYXRlZCB3aXRoIGFueSBvdGhlciBjb2x1
bW5jb250ZW50cy4NTm90ZSB0aGF0IGxvY2FsIHNob3VsZCBiZSB1c2VkIHdoZW4gdGhlIHNl
bWFudGljcyBvZiB0aGUgY29sdW1uY29udGVudCBhcmUgbm90IG1hdGNoYWJsZSwgbm90IHdo
ZW4gbWF0Y2hpbmcgaXMgbm90IGZlYXNpYmxlIGR1ZSB0byB0aGUgcmVwcmVzZW50YXRpb24u
ICBFLmcuLCB0aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgc3lzdGVtcyBmb3IgY2xhc3NpZmlj
YXRpb24gb2Ygb2JqZWN0cyBzbyB0aGF0IGEgZ2l2ZW4gdGFibGWScyBjbGFzc2VzIG1heSBu
b3QgYmUgY29ycmVsYXRhYmxlIHdpdGggb3RoZXJzIGluIHByYWN0aWNlLiAgSG93ZXZlciBz
dWNoIGEgY29sdW1uIHNob3VsZCBub3QgYmUgZ2l2ZW4gYSBwcm9wZXJ0eSBvZiBsb2NhbCwg
c2luY2UgdGhlIGJhc2UgY29uY2VwdCBvZiB3aGF0IGEgY2xhc3MgaXMsIGlzIHNoYXJlZCBi
eSBvdGhlciB0YWJsZXMgYW5kIG9uZSBjb3VsZCBpbWFnaW5lIHVzZWZ1bGx5IGpvaW5pbmcg
dGFibGVzIG9uIHRoaXMgaWRlYS4gIEhvd2V2ZXIsIHRoZSBqaXR0ZXIgaW4gdGhlIHRlbXBl
cmF0dXJlIG9mIHRoZSBmb3VydGggc3RhZ2UgcGhvdG9tdWx0aXBsaWVyIG9mIHNvbWUgaW5z
dHJ1bWVudCBpcyBqdXN0IG5vdCBzb21ldGhpbmcgdGhhdCBjYW4gdXNlZnVsbHkgYmUgY29t
cGFyZWQgd2l0aCBkYXRhIGluIGEgVk8gY29udGV4dCBhbmQgc2hvdWxkIGJlIGdpdmVuIHRo
ZSBhdHRyaWJ1dGUgbG9jYWwuDVRoaXMgZmlsbHMgYSBwb3RlbnRpYWxseSBzZXJpb3VzIGdh
cCBpbiB0aGUgb3JpZ2luYWwgcHJvcG9zYWwuICBUaGUgaWRlYSB3YXMgKEkgdGhpbmspIHRo
YXQgZm9yIHNheSBhIGJ1bmNoIG9mIGVuZ2luZWVyaW5nIGRhdGEgYSB1c2VyIHdvdWxkIGp1
c3Qgc3BlY2lmeSBhIFVDRCBvZiAoc2F5KSAgaW5zdHIuICBIb3dldmVyIHdlIG5vdyBuZWVk
IHRvIGhhdmUgYSBydWxlIGZvciB1bmRlcnN0YW5kaW5nIGhvdyBsb25nIGEgVUNEIG5lZWRz
IHRvIGJlIGJlZm9yZSBpdCBtYWtlcyBzZW5zZSB0byBjb21wYXJlIHRoZW0uICBJbiB0aGlz
IHByb3Bvc2FsIHRoZSBVQ0QgaXMgZ2l2ZW4gYXMgaW5zdHIubG9jYWwgc28gd2Ugc3RpbGwg
Z2l2ZSBhIGJpdCBvZiBpbmZvcm1hdGlvbiBhYm91dCB3aGF0IGlzIGluIHRoZSB0YWJsZSwg
YnV0IHdlIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgY29sdW1uY29udGVudCBzaG91bGRuknQg
ZXZlbiBiZSB0aG91Z2h0IG9mIGZvciBjcm9zcy1tYXRjaGluZy4HBw00LjMgRnJlZWRvbSBp
biBIaWVyYXJjaHkNVUNEcyBhdCBhbnkgbGV2ZWwgY2FuIGJlIHVzZWQgdG8gZGVzY3JpYmUg
c29tZSBwYXJhbWV0ZXIsIHdoZXRoZXIgc3ViLWxldmVscyBhcmUgZXhpc3Rpbmcgb3Igbm90
LiBUaGlzIHJ1bGUgaW1wbGllcyB0aGF0IHdlIGRvIG5vdCB1c2UgYSBxdWFsaWZpZXIgbGlr
ZSBtaXNjIG9yIGdlbjogaWYgYSBxdWFudGl0eSBpcyBub3QgYWNjdXJhdGVseSBkZWZpbmVk
LCB3ZSBqdXN0IHVzZSB0aGUgYHBhcmVudCcgVUNELiBBbiBleGFtcGxlIGNvbWVzIHdpdGgg
dGhlIGRpdmlzaW9uIG9mIHRoZSBlbGVjdHJvbWFnbmV0aWMgc3BlY3RydW06IHRoZSBzdGFu
ZGFyZCBVQ0Qgd29yZHRlcm1zIGNhbiBsYWJlbCBwYXJ0cyBvZiB0aGUgc3BlY3RydW0sIGZv
ciBleGFtcGxlIGVtLklSLjMtNHVtIGFuZCBlbS5JUi40LTh1bS4gVG8gbGFiZWwgYSByZWdp
b24gZnJvbSAzIHRvIDUgdW0sIHRoZSByZWNvbW1lbmRlZCBVQ0QgaXMgdGhlIGdlbmVyaWMg
ZW0uSVIuDQ00LjQgU3RhbmRhcmQgVXNhZ2UNVGhlIGVsZW1lbnRzIG9mIHRoZSB0cmVlIG1h
a2UgdXNlIG9mIGEgc3RhbmRhcmQgdm9jYWJ1bGFyeSwgaW4gdGhlIHNlbnNlIHRoYXQgYSBz
aW5nbGUgd29yZHRlcm0gaXMgdXNlZCB0byBkZXNpZ25hdGUgYSBwaHlzaWNhbCBjb25jZXB0
IG9yIHF1YW50aXR5LiBGb3IgaW5zdGFuY2UsIGlmIGVsZWN0cm9uIGlzIHVzZWQgdG8gZGVz
aWduYXRlIGFueSBlbGVjdHJvbi1yZWxhdGVkIHF1YW50aXR5LCB3ZSB3cml0ZSBlLmcuIHBo
eXMudGVtcC5lbGVjdHJvbiB0byBkZXNpZ25hdGUgdGhlIGVsZWN0cm9uaWMgdGVtcGVyYXR1
cmUgYW5kIG5vdCBhbiBhYmJyZXZpYXRpb24gbGlrZSBwaHlzLnRlbXAuZWw7IGNvbnZlcnNl
bHksIGVsZWN0cm9uIGtlZXBzIHRoZSBzYW1lIG1lYW5pbmcgYW1vbmcgYWxsIFVDRHMuIFdl
IHNob3VsZCB0cnkgdG8gbWFpbnRhaW4gYSBsaXN0IG9mIHRoZXNlIG1lYW5pbmdzIC0tIHdl
IGFyZSBmb3IgaW5zdGFuY2UgdXNpbmcgdGVtcCBmb3IgdGVtcGVyYXR1cmUsIHBoeXMgZm9y
IHBoeXNpY2FsLCBhbmQgc28gb24uDQ00LjUgVUNEcyBhbmQgUmVsYXRpb25zaGlwcyBhbW9u
ZyBDb25jZXB0cw0NVUNEcyBkZXNjcmliZSByZWxhdGlvbnNoaXBzIGFtb25nIGNvbmNlcHRz
IGluIHRocmVlIGRpc3RpbmN0IHdheXMuICANDVVDRHMgcHJvdmlkZSBhIHN0YW5kYXJkIGZy
YW1ld29yayBpbiB3aGljaCB3ZSBjYW4gY3JlYXRlIGxhYmVscyB3aG9zZSByZWxhdGlvbnNo
aXAgaXMgdW5kZXJzdG9vZCBhcyBleHBlcnQgaW5mb3JtYXRpb24gaW4gdGhlIGZpZWxkLiAg
W0RvdWJ0bGVzcyB0aGUgd29yZCBvbnRvbG9neSBiZWxvbmdzIGluIHRoaXMgcGFyYWdyYXBo
Ll0gRS5nLiwgdGhlcmUgaXMgbm90aGluZyBpbiB0aGUgdHdvIHN0cmluZ3MgcG9zLmVxLnJh
IGFuZCBwb3MuZXEuZGVjIHRoYXQgaW5kaWNhdGVzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2Vl
biBSaWdodCBBc2NlbnNpb24gYW5kIGRlY2xpbmF0aW9uLiAgSG93ZXZlciB1c2VycyBhbmQg
c29mdHdhcmUgdW5kZXJzdGFuZCB0aGF0IHJlbGF0aW9uc2hpcCBhbmQgVUNEcyBwcm92aWRl
IGNvbnNpc3RlbnQgbWFya2VycyB0byBlbmFibGUgdGhlIHVzZSBvZiB0aGF0IGtub3dsZWRn
ZS4gIFRoaXMgaXMgcGVyaGFwcyBqdXN0IGEgZmFuY3kgd2F5IG9mIHNheWluZyB0aGF0IFVD
RHMgcHJvdmlkZSBhIGNvbnNpc3RlbnQgd2F5IG9mIGxhYmVsaW5nIGNvbHVtbnMgliB1bmxp
a2UgY29sdW1uIG5hbWVzIHdoaWNoIHRlbmQgdG8gdmFyeSB3aWxkbHkuDQ0NVUNEcyBhbHNv
IGluZGljYXRlIHRoZSBjb21wYXJhYmlsaXR5IG9mIGNvbHVtbmNvbnRlbnRzLiAgVHdvIGNv
bHVtbmNvbnRlbnRzIHdpdGggdGhlIHNhbWUgVUNEIHNob3VsZCBiZSCRY29tcGFyYWJsZZIg
aW4gc29tZSBzZW5zZS4gIFRoZSBtb3JlIHByZWNpc2UgdGhlIFVDRCBpcywgdGhlIG1vcmUg
dXNlZnVsIHRoaXMgY29tcGFyYWJpbGl0eSBpcyBsaWtlbHkgdG8gYmUuIA0gVGhlIG5leHQg
c2VjdGlvbiB1c2VzIFVDRHMgb2Ygb2JqZWN0cywgdXN1YWxseSB3aXRoIHRoZSBhdHRyaWJ1
dGUgaW5zdGFuY2UuICBDb21wYXJhYmlsaXR5IG9mIHN1Y2ggVUNEcyBkb2VzIG5vdCBnZW5l
cmFsbHkgbWVhbiB0aGF0IHRoZXkgaGF2ZSB0aGUgc2FtZSBzdHJ1Y3R1cmUsIGJ1dCByYXRo
ZXIgdGhhdCB0aGVyZSBpcyBzb21lIHNlbnNlIHRoYXQgdGhlIHVuZGVybHlpbmcgaW5zdGFu
Y2VzIG1heSBiZSB0aGUgc2FtZS4gIEUuZy4sIHR3byBzb3VyY2UgdGFibGVzIG1heSBib3Ro
IGhhdmUgYSBVQ0Qgb2Ygc3JjLmluc3RhbmNlIGJ1dCBvbmUgbWF5IGNvbnRhaW4gZmx1eCBp
bmZvcm1hdGlvbiB3aGlsZSB0aGUgb3RoZXIgaGFzIHByb3BlciBtb3Rpb25zLiAgVGhlc2Ug
dGFibGVzIGFyZSBjb21wYXJhYmxlLCBiZWNhdXNlICByb3dzIG9mIHRoZSB0d28gdGFibGVz
IG1pZ2h0IGJlIHJlZmVycmluZyB0byB0aGUgc2FtZSBvYmplY3QuICBJLmUuLCB0aGUgdW5k
ZXJseWluZyBzb3VyY2UgaW5zdGFuY2UgaXMgdGhlIHNhbWUgZXZlbiB0aG91Z2ggdGhlIGF0
dHJpYnV0ZXMgb2YgdGhlIHNvdXJjZSBleHByZXNzZWQgaW4gdGhlIHRhYmxlcyBhcmUgdmVy
eSBkaWZmZXJlbnQuDUNvbHVtbkNvbnRlbnRzIG1heSBiZSBjb21wYXJhYmxlIGV2ZW4gaWYg
dGhleSBoYXZlIGRpZmZlcmVudCBVQ0RzLiAgR2VuZXJhbGx5IGlmIHRoZSB0d28gVUNEcyBj
YW4gYmUgbWFkZSBpZGVudGljYWwgYnkgb21pdHRpbmcgdGVybWluYWwgYXRvbXdvcmRzIGlu
IG9uZSBvciBtb3JlIHdvcmR0ZXJtcyBvZiB0aGUgVUNEcywgdGhlbiB0aGUgZmllbGRzIGFy
ZSBjb21wYXJhYmxlIHdoZW4gdGhvdWdodCBvZiBpbiB0aGUgbW9yZSBnZW5lcmljIGNvbnRl
eHQgb2YgdGhlIHRydW5jYXRlZCBVQ0QuICBFLmcuLCB0aGUgVUNEcyAgcGhvdC5mbHV4O2Vt
Lm9wdGljYWwuYmFuZC51O21lYXMuZXJyb3Iuc3RhdGlzdGljYWwgYW5kIHBob3QuZmx1eDtl
bS54cmF5LmhhcmQ7bWVhcy5lcnJvci5zeXN0ZW1hdGljIG1heSBiZSB0cnVuY2F0ZWQgdG8g
cGhvdC5mbHV4O2VtO21lYXMuZXJyb3IgYW5kIGNvbXBhcmVkIGFzIGluc3RhbmNlcyBvZiB0
aGlzIG1vcmUgZ2VuZXJpYyBVQ0QuDVNpbWlsYXJseSBpZiBVQ0RzIGRpZmZlciBpbiB0aGVp
ciBtb2RpZmllcnMgdGhleSBhcmUgY29tcGFyYWJsZSBhcyBVQ0RzIHdoZXJlIHRoZSBkaWZm
ZXJpbmcgY29udGV4dHMgaGF2ZSBiZWVuIG9taXR0ZWQuICBFLmcuLCBhIGNhbGN1bGF0ZWQg
YW5kIG1lYXN1cmVkIGZsdXggbWlnaHQgaGF2ZSBVQ0RzIHBob3QuZmx1eDtlbS5vcHRpY2Fs
O2ludGVudC5jYWxjdWxhdGVkO3ZhbHVlIGFuZCBwaG90LmZsdXg7ZW0ub3B0aWNhbDt2YWx1
ZS4gIFRoZXNlIGZsdXhlcyBhcmUgY29tcGFyYWJsZSBieSBpZ25vcmluZyB0aGUgaW50ZW50
IG9mIHRoZSBmaXJzdCBjb2x1bW4uICANV2hlbiBtb2RpZmllcnMgb3IgYXRvbXdvcmRzIGlu
IHRoZSBVQ0Qgd29yZHRlcm1zIGFyZSBpZ25vcmVkIHNvZnR3YXJlIGFuZCB1c2VycyBzaG91
bGQgYmUgYXdhcmUgdGhhdCB0aGUgZW50aXR5IGlzIGJlaW5nIHRyZWF0ZWQgaW4gYSBtb3Jl
IGdlbmVyaWMgY29udGV4dCB0aGFuIGl0IHdhcyBkZWZpbmVkIGluLg0NVGhlIGZpbmFsIHdh
eSB0aGF0IFVDRHMgZGVzY3JpYmUgcmVsYXRpb25zaGlwcyBpcyBpbiB0aGUgYXNzb2NpYXRp
b24gb2YgZGlmZmVyZW50IGF0dHJpYnV0ZXMgdG8gYSBnaXZlbiBiYXNlIGNvbmNlcHQgKG9y
IGJhc2UgY29uY2VwdCBhbmQgbW9kaWZpZXJzKS4gICBUaGUgYXR0cmlidXRlIHN0cnVjdHVy
ZXMgZGVmaW5lIGdlbmVyaWMgcmVsYXRpb25zaGlwcyBhbW9uZyBlbnRpdGllcywgZS5nLiwg
dGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGEgdmFsdWUgYW5kIGFuIGVycm9yIG9yIGJldHdl
ZW4gYW4gaW1hZ2UgYW5kIGEgc21vb3RoZWQgY291bnRlcnBhcnQuDQ1UbyBidWlsZCBhbiB1
bmRlcnN0YW5kaW5nIG9mIGRhdGEsIHdlIG5lZWQgdG8gYWRkcmVzcyBub3Qgb25seSB0aGUg
c2VtYW50aWMgcmVsYXRpb25zaGlwcyBhbW9uZyBjb25jZXB0cyB0aGF0IFVDRHMgcHJvdmlk
ZTogaS5lLiwgdGhlIGZsdXggY29uY2VwdCBpcyByZWxhdGVkIHRvIGVycm9ycyBpbiBmbHV4
ZXMsIGJ1dCBhbHNvIGEgcGh5c2ljYWwgcmVsYXRpb25zaGlwOiB0aGlzIHBhcnRpY3VsYXIg
Zmx1eCBpcyByZWxhdGVkIHRvIHRoaXMgcGFydGljdWxhciBlcnJvci4gIEhvdyB0aGlzIGlz
IGRvbmUsIGFuZCBob3cgdGhlIGNvbWJpbmF0aW9uIG9mIHNlbWFudGljIGFuZCBwaHlzaWNh
bCByZWxhdGlvbnMgYWxsb3dzIHVzZSB0byBidWlsZCBtb2RlbHMgb2YgVk8gZGF0YXNldHMg
aXMgZGVzY3JpYmVkIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbi4NSnVzdCBhIGZldyB3b3Jk
cyBoZXJlIHRvIHN1bW1hcml6ZSB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiB0aGlzIHByb3Bv
c2FsIGFuZCB0aGUgcHJvcG9zYWwgaXQgcmVzcG9uZHMgdG+FDSAgIFRoZSBiYXNpYyBkaWZm
ZXJlbmNlIGlzIHRoYXQgZXZlcnl0aGluZyByZXZvbHZlcyBhcm91bmQgdGhlIGJhc2UgY29u
Y2VwdHMsIG5vdCBwcm9wZXJ0aWVzLiBIZXJlIGFyZSBzb21lIHNwZWNpZmljIGRpZmZlcmVu
Y2VzOg0gICBUaGUgZnVuY3Rpb24gb2YgYSB3b3JkIGlzIGFsd2F5cyB0aGUgc2FtZS4gIEl0
IGNhbm5vdCBzb21ldGltZXMgYmUgYSBwcm9wZXJ0eSBhbmQgc29tZXRpbWVzIGEgY29uY2Vw
dC4gIA0gIE1hbnkgVUNEcyB0aGF0IHdvdWxkIHZhbGlkIGluIHRoZSBvbGQgc2NoZW1lIGFy
ZSBpbGxlZ2FsIGluIHRoaXMgb25lLiAgSW5kZWVkIEmSbSBub3Qgc3VyZSB0aGF0IGFueSBz
dHJpbmcgb2Ygd29yZHMgY2FuIGJlIGRldGVybWluZWQgdG8gYmUgaWxsZWdhbCBpbiB0aGUg
b2xkIHNjaGVtZS4gIFRoZSBvbmx5IHJlc3RyaWN0aW9uIG9uIHdvcmRzIHdhcyB0aGF0IHRo
ZSBmaXJzdCBiZSBhIHByb3BlcnR5LCBhbmQgdGhlcmUgaXMgbm8gd2F5IHRvIHRlbGwgd2hp
Y2ggd29yZHMgYXJlIHByb3BlcnRpZXMuIFRoaXMgc3RyaWN0bmVzcyBpcyBhIGdvb2QgdGhp
bmcgaWYgd2UgYW50aWNpcGF0ZSB1c2luZyBVQ0RzIGluIHNvZnR3YXJlLiAgRS5nLiwgc3Rh
dC5lcnJvciB3YXMgYSB2YWxpZCBVQ0QgZXZlbiB0aG91Z2ggaXQgd2FzIGNvbXBsZXRlbHkg
dW5jbGVhciB3aGF0IGl0IHJlZmVycmVkIHRvLiAgVUNEcyBjb3VsZCBiZSBidWlsdCBpbnRv
IGFyYml0cmFyaWx5IGxhcmdlIGFnZ2xvbWVyYXRpb25zLiAgVGhpcyBpcyBtdWNoIGhhcmRl
ciBpbiB0aGUgbmV3IHNjaGVtZSwgc2luY2Ugb25lIGNhbm5vdCBwdXQgaW4gYSBzZWNvbmQg
YmFzZSBjb25jZXB0LCBtb2RpZmllcnMgYXJlIHN0cmljdGx5IG9yZGVyZWQgYW5kIG1vc3Qg
b2YgdGhlIGF0dHJpYnV0ZXMgdGVuZCB0byBiZSBsaW1pdGluZy4gIEUuZy4sIHRoZSBzdGF0
aXN0aWNzIHRyZWVzIGRlY2ltYXRlcyB0aGUgZGltZW5zaW9uYWxpdHkgb2YgdGhlIHF1YW50
aXR5IHNvIGl0knMgaGFyZCB0byBpbWFnaW5lIFVDRHMgbGlrZSBjb25jZXB0O3N0YXQubWF4
O3N0YXQubWF4IGV2ZW4gdGhvdWdoIHRoZXkgbWF5IGJlIGxleGljYWxseSB2YWxpZC4gIElu
IHRoZSBwcmV2aW91cyBzY2hlbWUgVUNEcyBsaWtlOg0gICAgYXJpdGguZGlmZjthcml0aC5z
dW07cGhvdC5mbHV4O2VtLm9wdGljYWw7YXJpdGguc3VtO3Bob3QuZmx1eDtlbS5vcHRpY2Fs
O3Bob3QuZmx1eC54cmF5IA13ZXJlIGNsZWFybHkgaW4gdGhlIG9mZmluZyB3aXRoIGhvc3Rz
IG9mIHBhcmVudGhlc2lzIGFuZCBzdWNoLiAgIEFsbCBvZiB0aGlzIGNvbXBsZXggdHlpbmcg
b2Ygb25lIHRhYmxlIHRvIGFub3RoZXIgaGFzIGJlZW4gbW92ZWQgdG8gd2hlcmUgaXQgYmVs
b25ncyBpbiB0aGUgZ3JvdXBpbmcgc3RydWN0dXJlcyBkaXNjdXNzZWQgaW4gdGhlIG5leHQg
Y2hhcHRlci4NICAgVGhlIGZvcm1hdCBmb3IgVUNEcyBpcyBtdWNoIG1vcmUgdGlnaHRseSBj
b25zdHJhaW5lZCBhbmQgaXQgc2hvdWxkIGJlIG11Y2ggZWFzaWVyIHRvIGVuc3VyZSB0aGF0
IFVDRHMgZm9yIHRoZSBzYW1lIHF1YW50aXR5IGFyZSBhY3R1YWxseSB3cml0dGVuIGlkZW50
aWNhbGx5LiAgVGhlIHByZXZpb3VzIHNjaGVtZSBhbGxvd2VkIHN1YnN0YW50aWFsIGFtYmln
dWl0eSBpbiBob3cgYSBVQ0Qgc2hvdWxkIGJlIHdyaXR0ZW4gZXZlbiBpZiB0aGUgd29yZHMg
Y29tcHJpc2luZyB0aGUgVUNEIHdlcmUga25vd24uICBUaGlzIHdpbGwgbWFrZSBpdCBlYXNp
ZXIgdG8gYnVpbGQgVUNEcyBhbmQgdG8gYXV0b21hdGljYWxseSBwYXJzZSB0aGVtLiAgDSAg
T25seSBhIHNpbmdsZSBiYXNlIGNvbmNlcHQgY2FuIGFwcGVhciBpbiBhIFVDRC4gIFJlbGF0
aW9uc2hpcHMgYW1vbmcgYmFzZSBjb25jZXB0cyBhcmUgYWRkcmVzc2VkIHVzaW5nIHRoZSBn
cm91cGluZyBzdHJ1Y3R1cmUgZGlzY3Vzc2VkIGluIHRoZSBmb2xsb3dpbmcgY2hhcHRlci4N
ICBUaGUgb3JkZXIgb2YgcHJvcGVydGllcyBhbmQgY29uY2VwdHMgaXMgcmV2ZXJzZWQgYW5k
IG1pcnJvcnMgdGhlIGNvbnZlbnRpb25hbCByZXByZXNlbnRhdGlvbnMgb2Ygb2JqZWN0cyBh
bmQgYXR0cmlidXRlcy4gDSAgRXJyb3IgaXMgbW92ZWQgdG8gYSBuZXcgbWVhcyB0cmVlLiAg
SSB3b3VsZCBzdWdnZXN0IHRoaXMgZXZlbiBmb3IgdGhlIHByZXZpb3VzIHNjaGVtZS4gIEVy
cm9ycyBhcmUgbm90IGEgc3RhdGlzdGljYWwgcHJvcGVydHkgliB0aGV5IGFyaXNlIGZyb20g
dGhlIHBoeXNpY3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBtZWFzdXJlbWVudC4gIFRoaXMgYWxz
byBhbGxvd3MgYSB1c2VmdWwgc2VwYXJhdGlvbiBvZiBzdGF0IGFuZCBmaWx0ZXIgYXR0cmli
dXRlcy4NICBUaGUgbG9jYWwgcHJvcGVydHkgaXMgYWRkZWQuICBTb21ldGhpbmcgc2ltaWxh
ciB3b3VsZCBiZSBhcHByb3ByaWF0ZSBpbiB0aGUgb2xkIHNjaGVtZS4NICBTZXZlcmFsIG5l
dyB3b3JkdGVybSB0cmVlcyBhcmUgZGVmaW5lZCBhcyB3ZWxsIGFzIGEgZmV3IHNwZWNpYWwg
c2luZ2xlIHdvcmQgYXR0cmlidXRlcy4gIFRoZSBsYXR0ZXIgYXJlIGltcG9ydGFudCBmb3Ig
dGhlIGRpc2N1c3Npb24gaW4gc2VjdGlvbiA1LiAgTW9zdCBvZiB0aGUgdHJlZXMgYXJlIHNp
bXBsZSByZWZsZWN0aW9ucyBvZiB3aGF0IEkgc2VlIGFzIGhvbGVzIGluIHRoZSBVQ0QgY292
ZXJhZ2UgYnV0IHRoZXkgcHJvYmFibHkgYXJlbpJ0IGNyaXRpY2FsIGFuZCBoYXZlIG5vdGhp
bmcgcmVhbGx5IHRvIGRvIHdpdGggdGhlIGRpZmZlcmVuY2UgaW4gc2NoZW1hcy4gIEkgaGF2
ZW6SdCBhY3R1YWxseSBzZWVuIHRoZSBmdWxsIHRyZWUgb2YgVUNEcyBmb3IgdGhlIG5ldyBw
cm9wb3NhbC4gIE9uZSBpbXBvcnRhbnQgaXNzdWUgd2l0aCBteSBwcm9wb3NhbCBpcyB0aGF0
IEkgd291bGQgbGlrZSB1c2VycyB0byBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIGF0dHJpYnV0
ZXMsIHZhbHVlcyBhbmQgY29uY2VwdHMgYnkgbG9va2luZyBvbmx5IGF0IHRoZSBmaXJzdCBh
dG9td29yZCBvZiBhIGdpdmVuIHdvcmR0ZXJtIGFuZCBub3QgcmVwZWF0IHdvcmR0ZXJtcyBp
biB0aG9zZSB0aHJlZSBjYXRlZ29yaWVzLiAgVGhpcyBpcyBtYW5pZmVzdGx5IHBvc3NpYmxl
IChlLmcuLCBJIGNvdWxkIHNpbXBseSBjcmVhdGUgbmV3IHRyZWVzIGFzIG5lZWRlZCksIGFu
ZCBJIHRoaW5rIGl0IGV2ZW4gd29ya3Mgb3V0IG5pY2VseSwgYnV0IHRoZSBwcm9vZiBpcyBp
biB0aGUgcHVkZGluZy4NICBUaGUgYWxpYXMgY29uY2VwdCBpcyBkZWxldGVkLiAgVGhlIHdo
b2xlIGlkZWEgb2YgVUNEcyBpcyB0byBiZSBzdGFuZGFyZCBhbmQgc28gSSB0aGluayBpdJJz
IGEgYmFkIGlkZWEuIGJ1dCBwZXJoYXBzIEkgbWlzdW5kZXJzdGFuZCBpdC4NDTUuIFVDRHMg
aW4gQ29tcGxleCBTdHJ1Y3R1cmVzLg0NVGhpcyBmb2xsb3dpbmcgZGlzY3Vzc2lvbiBpcyBs
YXJnZWx5IGluZGVwZW5kZW50IG9mIHdoZXRoZXIgd2UgY2hvb3NlIHRoZSBvcmlnaW5hbCBV
Q0QyIGZyYW1ld29yayBvciB3aGF0IEkgaGF2ZSBkZXNjcmliZWQgYWJvdmUuICBIb3dldmVy
IHRoaXMgYXBwcm9hY2ggZW5hYmxlcyB1cyB0byBidWlsZCBjb21wbGV4IGNvbmNlcHRzIGZy
b20gdGhlIHNpbXBsZSAgVUNEcyBzbyB0aGF0IHRoZSBVQ0RzIHRoZW1zZWx2ZXMgYmVhciBt
dWNoIGxlc3Mgd2VpZ2h0IGluIGRlc2NyaWJpbmcgdGhlIG9yZ2FuaXphdGlvbiBvZiBkYXRh
LiAgUGVyc29uYWxseSBJIGJlbGlldmUgdGhpcyBhcHByb2FjaCB3aWxsIGxhcmdlbHkgb2J2
aWF0ZSB0aGUgbmVlZCBmb3IgdXR5cGVzIGluIFZPVGFibGVzLiAgSSB3b3VsZCBiZSB2ZXJ5
IGludGVyZXN0ZWQgaW4gb3RoZXIgcmVhY3Rpb25zLg1UaGUgcmVjZW50IHByb3Bvc2FsIGZv
ciBncm91cGluZyBzdHJ1Y3R1cmVzIHdpdGhpbiBWT1RhYmxlcyBtYWtlcyBpdCBwb3NzaWJs
ZSB0byB1c2UgVUNEcyAgaW4gYSBtdWNoIG1vcmUgc29waGlzdGljYXRlZCB3YXkgdGhhbiB3
YXMgcG9zc2libGUgd2hlbiB0YWJsZXMgY291bGQgY29tcHJpc2Ugb25seSBhIGxpbmVhciBh
cnJheSBvZiBjb2x1bW5zLiAgVUNEcyBhcmUgbm90IG5lY2Vzc2FyaWx5IHRpZWQgdG8gVk9U
YWJsZXMsIGJ1dCB3ZSByZWNvbW1lbmQgdGhhdCBncm91cGluZyBzdHJ1Y3R1cmVzIHNob3Vs
ZCBiZSBhdmFpbGFibGUgYW5kIHVzZWQgd2hlbmV2ZXIgVUNEcyBhcmUgdXNlZCBpbiBvdGhl
ciBjb250ZXh0cyB0byBkZXNjcmliZSB0YWJ1bGFyIGluZm9ybWF0aW9uLiAgRnJvbSB0aGUg
cGVyc3BlY3RpdmUgb2YgVUNEcyB0aGUga2V5IGVsZW1lbnRzIG9mIHRoZSBncm91cCBhcmUg
dGhhdCBpdCCRcGh5c2ljYWxseZIgYXNzb2NpYXRlcyBhIGdyb3VwIG9mIGNvbHVtbnMsIGFu
ZCB0aGF0IHRoZXJlIGlzIGEgZ3JvdXAgVUNELiAgQSBVQ0QgZm9yIHRhYmxlcyBhcyBhIHdo
b2xlIHdpbGwgYWxzbyBiZSBleHRyZW1lbHkgdmFsdWFibGUuDVdoZW4gd2Ugc2F5IHRoYXQg
dGhlIGdyb3VwIHBoeXNpY2FsbHkgYXNzb2NpYXRlcyBlbnRpdGllcywgYWxsIHdlIG1lYW4g
aXMgdGhhdCBieSBwbGFjaW5nIGVudGl0aWVzIHdpdGhpbiBhIGdyb3VwIHRoZSB0YWJsZSBi
dWlsZGVyIGlzIGRlY2xhcmluZyB0aGF0IHRoZXNlIGVudGl0aWVzIGFyZSBsaW5rZWQgdG9n
ZXRoZXIgaW4gc29tZSByZWxhdGlvbnNoaXAuICBUaGUgZ3JvdXBpbmcgZG9lcyBub3QgZGVz
Y3JpYmVzIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHJlbGF0aW9uc2hpcC4gIFRoYXQgaXMgdGhl
IHJvbGUgb2YgVUNEcy4gIEdlbmVyYWxseSB0aGUgZ3JvdXBlZCBlbnRpdGllcyBtYXkgYmUg
dGhvdWdodCBvZiBhcyBhdHRyaWJ1dGVzIG9mIHRoZSBlbnRpdHkgZGVzY3JpYmVkIGluIHRo
ZSBncm91cGluZyBVQ0QuICAgDUdyb3VwcyBzaG91bGQgYmUgdXNlZCBpbiBhIHRhYmxlIHdo
ZW5ldmVyIHR3byBvciBtb3JlIGNvbHVtbnMgKG9yIHBhcmFtZXRlcnMpIGFyZSByZWxhdGVk
IHRvIG9uZSBhbm90aGVyIGluIHNvbWUgd2F5IG90aGVyIHRoYW4gYXMgYmVpbmcgZGlzdGlu
Y3QgYXR0cmlidXRlcyB3aXRoaW4gdGhlaXIgZW5jbG9zaW5nIHRhYmxlIChvciBncm91cCku
ICBUYWJsZSBhbmQgZ3JvdXAgVUNEcyBhcmUgdXN1YWxseSBzaW1wbGUgdHdvIHdvcmR0ZXJt
IFVDRHMuICBUaGUgdXNlIG9mIGdyb3VwcyBhbmQgdGFibGUgVUNEcyBpcyBkZXNjcmliZWQg
YmVsb3cgdXNpbmcgYSBzZXJpZXMgb2YgZXhhbXBsZXMuICBUaGVzZSBleGFtcGxlcyB1c2Ug
YSBzaW1wbGUgZ3JhcGhpYywgdGhlICBVQ0R0cmVlIHRvIHJlcHJlc2VudCB0aGUgVUNEcyB3
aXRoaW4gYSB0YWJsZS4gIEVhY2ggVUNEIGlzIHBsYWNlZCBvbiBpdHMgb3duIGxpbmUgb2Nj
YXNpb25hbGx5IHdpdGggYSBjb21tZW50IGZvbGxvd2luZy4gIFdoaXRlc3BhY2Ugc2VwYXJh
dGVzIHRoZSBVQ0QgZnJvbSBhbnkgY29tbWVudC4gIFRoZSB0YWJsZSBVQ0QgaXMgb24gdGhl
IGZpcnN0IGxpbmUgYW5kIGlzIG5vdCBpbmRlbnRlZC4gIFdoZW5ldmVyIHdlIGdvIGludG8g
YSBncm91cCBvciB0YWJsZSB0aGUgc3Vic2VxdWVudCBsaW5lcyBhcmUgaW5kZW50ZWQgb25l
IG1vcmUgdGFiLiAgVGhpcyBpbW1lZGlhdGUgaWxsdXN0cmF0ZXMgdGhlIGdyb3VwIHN0cnVj
dHVyZSBvZiB0aGUgdGFibGUuDS4NRXhhbXBsZSAxOiAgQSBzaW1wbGUgdGFibGUgZ2l2aW5n
IHRoZSBpZCwgcG9zaXRpb24gYW5kIGZsdXggb2YgYSBzZXQgb2Ygc291cmNlcy4Nc3JjO2lu
c3RhbmNlCQkJCVRoZSB0YWJsZSBVQ0QsIHNpbmNlIHRoaXMgZGVmaW5lcyBhIGdyb3VwIHN1
YnNlcXVlbnQNICAgICAgICAgICAgIAkJCQlsaW5lcyBhcmUgaW5kZW50ZWQNCW1ldGEuaWQ7
dmFsdWUJCQlBIGNvbHVtbiBVQ0QNCXBvcy5lcTtpbnN0YW5jZQkJCUEgZ3JvdXAgVUNEIJYg
c2luY2UgdGhlIG5leHQgY29sdW1uIGlzIGluZGVudGVkIG1vcmUNCQlwb3MuZXEucmE7dmFs
dWUJQSBjb2x1bW4gVUNEDQkJcG9zLmVxLmRlYzt2YWx1ZQlBIGNvbHVtbiBVQ0QNCXBob3Qu
Zmx1eDt2YWx1ZQkJQSBjb2x1bW4gVUNEDQ1UaGlzIGlzIHRoZSBVQ0RUcmVlIGZvciBhIHNp
bXBsZSB0YWJsZSB3aXRoIGFuIGlkLCBwb3NpdGlvbiBhbmQgZmx1eCBmb3IgYSBzZXQgb2Yg
c291cmNlcy4gIFRoZSB0YWJsZSBVQ0QgaW5kaWNhdGVzIHRoYXQgZWFjaCByb3cgaW4gdGhl
IHRhYmxlIHJlcHJlc2VudHMgb25lIHNvdXJjZS4gICBUaGUgSUQgYW5kIGZsdXggYXJlIGdp
dmVuIHVzaW5nIHNpbXBsZSB2YWx1ZSBVQ0RzLCBidXQgc2luY2UgUkEgYW5kIERlYyBhcmUg
cmVsYXRlZCB0byBlYWNoIG90aGVyIHRoZXkgYXJlIGdyb3VwZWQgYXMgYSBwb3NpdGlvbiBp
bnN0YW5jZS4NVGhlIFZPVGFibGUgWE1MIGZvciAgdGhlIGhlYWRlciBvZiB0aGlzIHRhYmxl
IG1pZ2h0IGxvb2sgc29tZXRoaW5nIGxpa2U6DTxUQUJMRSCFIHVjZD2Sc3JjO2luc3RhbmNl
kj4NICAgPEZJRUxEIIUgdWNkPZJtZXRhLmlkki8+DSAgIDxHUk9VUCCFIHVjZD2ScG9zLmVx
O2luc3RhbmNlkj4NICAgICAgPEZJRUxEIIUgdWNkPZJwb3MuZXEucmGSLz4NICAgICAgPEZJ
RUxEIIUgdWNkPZJwb3MuZXEuZGVjki8+DSAgPC9HUk9VUD4NICA8RklFTEQghSB1Y2Q9knBo
b3QuZmx1eJIvPg2FDTwvVEFCTEU+DU9ubHkgdGhlIFVDRCByZWxldmFudCBlbGVtZW50cyBv
ZiB0aGUgWE1MIHRhYmxlIGhhdmUgYmVlbiBnaXZlbi4gIE5vdGUgdGhlIHVzZSBvZiB0aGUg
Y29udmVudGlvbiBhbGxvd2luZyB0aGUgb21pc3Npb24gb2YgdGhlIHZhbHVlIGF0dHJpYnV0
ZS4NU29mdHdhcmUgdGhhdCBrbm93cyBub3RoaW5nIG9mIGdyb3VwIFVDRHMgd2lsbCB3b3Jr
IGZpbmUgaGVyZS4gIEl0IHdpbGwgZmluZCB0aGUgUkEgYW5kIERlYyBhbmQgZmx1eCBjb2x1
bW5zIHdpdGhvdXQgYW55IHRyb3VibGUuICBXZSBkb26SdCBsb3NlIGFueXRoaW5nIGJ5IHVz
aW5nIGdyb3Vwcy4gIA0NTm93IGxldCB1cyBjb25zaWRlciBtb3JlIGNvbXBsZXggY2FzZXMs
IHRvIHNlZSB0aGUgcmVhbCBwb3dlciBvZiBjb21iaW5pbmcgVUNEcyBhbmQgZ3JvdXBzLiAg
SW4gdGhlIG9sZCBVQ0Qgc2NoZW1hIFVDRHMgd2l0aCCRbWFpbpIgYXR0cmlidXRlcyBhcmUg
bmVlZGVkIHRvIHJlc29sdmUgYW1iaWd1aXRpZXMgYW1vbmcgY29sdW1ucyB3aXRoIHNpbWls
YXIgVUNELCBidXQgdGhpcyBrbHVkZ2UgZmFpbHMgYXMgdGFibGVzIGdldCBldmVuIG1vZGVz
dGx5IGNvbXBsZXguDQ1FeGFtcGxlIDI6ICBBIHNvdXJjZSB0YWJsZSB3aXRoIHRoZSBvYnNl
cnZhdGlvbiBwbGF0ZSBjZW50ZXIgYW5kIGFuIG9ic2VydmF0aW9uIHRhYmxlIHdpdGggYSBn
dWlkZSBzdGFyIHBvc2l0aW9uLg1zcmMuaW5zdGFuY2UgICAgICAgICAgICAgICAgICAgICAg
ICAgCVRoaXMgaXMgdGhlIHNvdXJjZSB0YWJsZQ0JbWV0YS5pZDt2YWx1ZQkJCVRoZSBpZCBv
ZiB0aGUgc291cmNlDQlwb3MuaW5zdGFuY2VlcQ0JCXBvcy5lcS5yYQkJVGhlIFJBIGZvciB0
aGUgc291cmNlDQkJcG9zLmVxLmRlYwkJVGhlIERlYyBmb3IgdGhlIHNvdXJjZQ0Jb2JzLmlu
c3RhbmNlZXENCQltZXRhLmlkO3ZhbHVlCQlUaGUgSUQgb2YgdGhlIHBsYXRlDQkJcG9zLmlu
c3RhbmNlZXENCQkJcG9zLmVxLnJhCVRoZSBSQSBmb3IgdGhlIHBsYXRlIGNlbnRlcg0JCQlw
b3MuZXEuZGVjCVRoZSBkZWNsaW5hdGlvbiBmb3IgdGhlIHBsYXRlIGNlbnRlcg0JcGhvdC5m
bHV4O3ZhbHVlCQlUaGUgZmx1eCBvZiB0aGUgc291cmNlDQ0Nb2JzLmluc3RhbmNlCQkJVGhp
cyBpcyB0aGUgb2JzZXJ2YXRpb24gdGFibGUNCXNyYy5pbnN0YW5jZQkJCQkNCQltZXRhLmlk
O3ZhbHVlCQkJVGhlIGlkL25hbWUgb2YgdGhlIGd1aWRlIHN0YXINCQlwb3MuaW5zdGFuY2Vl
cQ0JCQlwb3MuZXEucmE7dmFsdWUJVGhlIFJBIG9mIHRoZSBndWlkZSBzdGFyDQkJCXBvcy5l
cS5kZWM7dmFsdWUJVGhlIGRlY2xpbmF0aW9uIG9mIHRoZSBndWlkZSBzdGFyDQltZXRhLmlk
O3ZhbHVlCQkJCVRoZSBpZCBvZiB0aGUgb2JzZXJ2YXRpb24NCXBvcy5pbnN0YW5jZWVxDQkJ
cG9zLmVxLnJhCQkJVGhlIFJBIG9mIHRoZSBjZW50ZXIgb2YgdGhlIG9ic2VydmF0aW9uDQkJ
cG9zLmVxLmRlYwkJCVRoZSBkZWNsaW5hdGlvbiBvZiAgdGhlIG9ic2VydmF0aW9uLg0JdGlt
ZS5leHBvc3VyZTt2YWx1ZQkJCVRoZSBleHBvc3VyZSB0aW1lIG9mIHRoZSBvYnNlcnZhdGlv
bg0NDVRoZXNlIHR3byBVQ0RUcmVlcyBtZXJpdCBjYXJlZnVsIHN0dWR5LiAgVGhpcyBleGFt
cGxlIGlzIGNvbnRyaXZlZCBzdWNoIHRoYXQsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUg
bGFzdCBjb2x1bW4sIHRoZSBjb2x1bW4gVUNEcyBpbiB0aGVzZSB0d28gdGFibGVzIGFyZSBp
ZGVudGljYWwgYW5kIGluIHRoZSBzYW1lIG9yZGVyIHlldCBib3RoIHNvZnR3YXJlIGFuZCBo
dW1hbnMgc2hvdWxkIGhhdmUgbm8gdHJvdWJsZSBkaXN0aW5ndWlzaGluZyB0aGUgdmVyeSBk
aWZmZXJlbnQgc2VtYW50aWNzIG9mIHRoZSB0d28gdGFibGVzLg0NRmlyc3QsIHRoZSB0YWJs
ZSBVQ0RzIGluZGljYXRlIHRoZSBiYXNpYyBzZW5zZSBvZiB3aGF0IGVhY2ggcm93IGluIHRo
ZSB0YWJsZXMgaXMuICBTb2Z0d2FyZSBvciBwZW9wbGUgY2FuIHNlZSB0aGF0IHdlIGdldCBp
bmZvcm1hdGlvbiBhYm91dCBzb3VyY2VzIGluIHRoZSBmaXJzdCB0YWJsZSwgYW5kIGluZm9y
bWF0aW9uIGFib3V0IG9ic2VydmF0aW9ucyBpbiB0aGUgc2Vjb25kLg0NTmV4dCwgdG8gZmlu
ZCB0aGUgcHJpbWFyeSBwb3NpdGlvbiAob3IgaWQpIGZpZWxkcyB3ZSBzaW1wbHkgbG9vayBm
b3IgdGhlIHBvc2l0aW9uIGZpZWxkIHdoaWNoIGlzIGxlYXN0IGluZGVudGVkLCBjbG9zZXIg
dG8gdGhlIHJvb3QgdGFibGUgVUNELiAgVGhpcyBzaW1wbGUgYXBwcm9hY2ggd2lsbCBvYnZp
YXRlIHRoZSBuZWVkIGZvciCRbWFpbpIgcXVhbGlmaWVycy4gIE5vdGUgdGhhdCB0aGUgb3Jk
ZXIgb2YgdGhlIGNvbHVtbnMgaXMgbm90IHNpZ25pZmljYW50IJYgaXQgaXMgdGhlIHRhYmxl
IHN0cnVjdHVyZSB0aGF0IHJldmVhbHMgdGhlIHByaW1hcnkgZmllbGRzLg0NRmluYWxseSBj
b25zaWRlciBhIHNpdHVhdGlvbiB3aGVyZSBhIHVzZXIgaXMgbG9va2luZyBmb3IgdGhlIHBv
c2l0aW9ucyBvZiBzb3VyY2VzIGFuZCBkb2VzIG5vdCBjYXJlIGlmIHRoZSBpbmZvcm1hdGlv
biBpcyBhIHByaW1hcnkgYXR0cmlidXRlIG9mIHRoZSB0YWJsZS4gIFRoZXJlknMgbm8gcHJv
YmxlbSB3aXRoIHRoZSBmaXJzdCB0YWJsZSBuYXR1cmFsbHkgliBpdCBpcyBhIHNvdXJjZSB0
YWJsZSBhZnRlciBhbGwuICBCdXQgdGhlIHNlY29uZCB0YWJsZSBtYW5pZmVzdGx5IGhhcyBz
dWNoIGluZm9ybWF0aW9uIHRvbyBhbmQgdGhlIHVzZXIgY2FuIGVhc2lseSBmaW5kIGl0LiAg
V2hhdCBpcyBxdWl0ZSByZW1hcmthYmxlIGlzIHRoYXQgdXNlciBjYW4gZ2V0IHRoZSBzb3Vy
Y2UgcG9zaXRpb25zIGluIGEgbm9uLXNvdXJjZSB0YWJsZSBieSBtYWtpbmcgZXhhY3RseSB0
aGUgc2FtZSBxdWVyeSBvZiB0aGUgc2Vjb25kIHRhYmxlIGFzIG9mIHRoZSBmaXJzdDogZmlu
ZCBhIHBvcyBlbnRyeSBpbiBhIHNyYyBjb250ZXh0LiAgIEVzc2VudGlhbGx5IHRoZSB1c2Vy
IGNhbiBzcGVjaWZ5IGEgbW9kZWwgliBhIGRhdGEgbW9kZWwgliBmb3IgdGhlIGluZm9ybWF0
aW9uIHRoZXkgYXJlIGxvb2tpbmcgZm9yIGFuZCBmaW5kIGl0IHJlZ2FyZGxlc3Mgb2YgaXRz
IGRlcHRoIGluIHRoZSB0YWJsZS4gICBUaGlzIGlzIGV4YWN0bHkgdGhlIGtpbmQgb2YgcXVl
cnkgb24gaGllcmFyY2hpY2FsIGRhdGEgdGhhdCBYUXVlcnkgaGFzIGJlZW4gZGV2ZWxvcGVk
IGZvci4NDQ0NDQ0NDQ0NRXhhbXBsZSAzOiBUd28gZXhhbXBsZXMgb2YgdHdvIHNvdXJjZXMg
aW4gYSB0YWJsZS4Nc3JjLmluc3RhbmNlDQlwaHlzLndhdmVsZW5ndGg7dmFsdWUNCXBob3Qu
Zmx1eDt2YWx1ZQ0Jc3JjLmluc3RhbmNlDQkJcGhvdC5mbHV4O3ZhbHVlDQ0Nc3JjLm11bHRp
cGxldA0JcGh5cy53YXZlbGVuZ3RoO3ZhbHVlDQlzcmMuaW5zdGFuY2UNCQlwaG90LmZsdXg7
dmFsdWUNCXNyYy5pbnN0YW5jZQ0JCXBob3QuZmx1eDt2YWx1ZQ0NSGVyZSB3ZSBoYXZlIHR3
byB0YWJsZXMgd2l0aCB0aHJlZSBjb2x1bW5zIHdpdGggaWRlbnRpY2FsIFVDRHMsIGJ1dCB0
aGUgZ3JvdXBpbmcgVUNEcyBhcmUgcXVpdGUgZGlmZmVyZW50LiAgV2hhdCBjb3VsZCB0aGlz
IG1lYW4/DQ1UaGUgdGFibGVzIHNlZW0gdG8gYmUgc3BlY3RyYSBzaW5jZSB3ZSBoYXZlIGEg
Zmx1eCBhbmQgd2F2ZWxlbmd0aCBmb3IgZWFjaCByb3cuICAgSW4gdGhlIGZpcnN0IGNhc2Ug
dGhlcmUgaXMgYWxzbyBhIHNvdXJjZSB3aGljaCBpcyBhbiBhdHRyaWJ1dGUgb2YgdGhlIHRh
YmxlIHNvdXJjZS4NDUluIHRoZSBzZWNvbmQgdGhlcmUgYXJlIHR3byBzb3VyY2VzIHRoYXQg
YXJlIG5vdCBkZXBlbmRlbnQgb24gb25lIGFub3RoZXIuICBUaGUgbXVsdGlwbGV0IGF0dHJp
YnV0ZSBvZiB0aGUgdGFibGUgVUNEIHN1Z2dlc3RlZCB0aGF0IHdlIHdvdWxkIGhhdmUgbW9y
ZSB0aGFuIG9uZSBpbnN0YW5jZSBpbiBlYWNoIHJvdyBhbmQgdGhlIGRldGFpbGVkIGV4YW1p
bmF0aW9uIG9mIHRoZSBVQ0RUcmVlIGNvbmZpcm1zIHRoaXMuICBBcHBhcmVudGx5IHRoZSB3
YXZlbGVuZ3RoIGNvbHVtbiBpcyBzaGFyZWQgYnkgZWFjaCBvZiB0aGVzZSB0d28gc291cmNl
IGluc3RhbmNlcy4gIA0NVGhlIGZpcnN0IHRhYmxlIHdvdWxkIGJlIGFwcHJvcHJpYXRlIHdo
ZXJlIHRoZSBzZWNvbmQgZmx1eCB2YWx1ZSBpcyBmcm9tIGEgY2FsaWJyYXRvciBvYmplY3Qu
ICBUaGUgY2FsaWJyYXRpb24gb2JqZWN0IGlzIGNvbnNpZGVyZWQgYXMgYW4gYXR0cmlidXRl
IG9mIHRoZSBwcmltYXJ5IHNvdXJjZS4gIFNvIGlmIHdlIHdhbnQgdG8gZmluZCB0aGUgZmx1
eCBmb3IgdGhlIHByaW1hcnkgc291cmNlIHdlIGxvb2sgYXQgdGhlIGxlc3MgaW5kZW50ZWQg
Y29sdW1uLg0NVGhlIHNlY29uZCB0YWJsZSB3b3VsZCBiZSBhcHByb3ByaWF0ZSBpZiB3ZSBo
YXBwZW4gdG8gaGF2ZSBhIGRldGVjdG9yIHRoYXQgdGFrZXMgdHdvIHNwZWN0cmEgb2YgaW5k
ZXBlbmRlbnQgdGFyZ2V0cyBhbmQgcmVjb3JkcyB0aGVtIHRvZ2V0aGVyLiAgVGhlIHR3byBz
b3VyY2VzIGFyZSBhc3NvY2lhdGVkIHBoeXNpY2FsbHkgaW4gdGhlIHRhYmxlIJYgdGhleSB3
ZXJlIG9ic2VydmVkIGF0IHRoZSBzYW1lIHRpbWUgcGVyaGFwcyAtLSBidXQgdGhlcmUgaXMg
bm8gc2VtYW50aWMgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlbSwgb3IgYXQgbGVhc3Qgbm9u
ZSB0aGF0IHRoZSB0YWJsZSBjcmVhdG9yIGNob3NlIHRvIGV4cHJlc3MuICAgSXQgaXMgaW1w
b3J0YW50IHRoYXQgb3VyIHNlbWFudGljIGZyYW1ld29yayBpcyBhYmxlIHRvIGluZGljYXRl
IGxhY2sgb2YgcmVsYXRpb25zaGlwIGp1c3QgYXMgZWFzaWx5IGFzIHJlbGF0aW9uc2hpcC4N
DU9uZSBpbnRlcmVzdGluZyBpc3N1ZSBoZXJlIGlzIHdoYXQgd2UgY2hvb3NlIGZvciB0aGUg
dGFibGUgVUNELiAgSGVyZSB0aGUgVUNEIGluZGljYXRlcyB0aGF0IHRoaXMgaXMgaW5mb3Jt
YXRpb24gYWJvdXQgYSBzb3VyY2UsIGJ1dCBpdCBjb3VsZCBwZXJoYXBzIGhhdmUgdXNlZCBh
IHBob3QuZmx1eDtpbnN0YW5jZSBvciBwaG90LmZsdXg7bXVsdGlwbGV0LiAgQSBjYXNlIGNh
biBiZSBtYWRlIGZvciBib3RoIGJ1dCB3ZSBzaG91bGQgdHJ5IHRvIGFncmVlIG9uIGFwcHJv
cHJpYXRlIHRlbXBsYXRlcyB0byBiZSB1c2VkIHdpdGhpbiB0aGUgVk8uDQ0NDQ0NRXhhbXBs
ZSA0OiBTb3VyY2UgY3Jvc3MtY29ycmVsYXRpb25zLg1PbmUgb2YgdGhlIGNvbW1vbmVzdCBv
cGVyYXRpb25zIHdlIGFudGljaXBhdGUgaW4gdGhlIFZpcnR1YWwgT2JzZXJ2YXRvcnkgaXMg
dGhlIGNvcnJlbGF0aW9uIG9mIHR3byBvYmplY3QgdGFibGVzLiAgV2UgY2FuIG1ha2UgcXVp
dGUgc3VidGxlIGRpc3RpbmN0aW9ucyBhYm91dCB0aGUgcmVzdWx0cyBvZiBzdWNoIGEgY29y
cmVsYXRpb24gYnkgaG93IHdlIHN0cnVjdHVyZSB0aGUgcmVzdWx0aW5nIG91dHB1dC4gIENv
bnNpZGVyDQ1zcmMubXVsdGlwbGV0DQlzcmMuaW5zdGFuY2UNCQltZXRhLmlkO3ZhbHVlCQlU
aGUgU2xvYW4gSUQNCQlwb3M7aW5zdGFuY2UJCVRoZSBTbG9hbiBwb3NpdGlvbiAodGhlIGFj
dHVhbCBjb2x1bW5zIGFyZSBzdXBwcmVzc2VkKQ0JCXBob3QuZmx1eDtlbS5vcHRpY2FsO3Zh
bHVlCUEgU2xvYW4gRmx1eA0Jc3JjLmluc3RhbmNlDQkJbWV0YS5pZDt2YWx1ZQkJVGhlIDJN
QVNTIElEDQkJcG9zLmluc3RhbmNlCQlUaGUgMk1BU1MgcG9zaXRpb24NCQlwaG90LmZsdXg7
ZW0uaW5mcmFyZWQ7dmFsdWUJVGhlIDJNQVNTIGZsdXgNCXBoeXMuZGVncmVlczt2YWx1ZQkJ
VGhlIG9mZnNldCBiZXR3ZWVuIHRoZSB0d28gdGFyZ2V0cw0NVGhpcyByZXByZXNlbnRhdGlv
biBvZiB0aGUgdGFibGUgc3VnZ2VzdHMgdGhhdCBlYWNoIHJvdyBpcyBhIGNhbmRpZGF0ZSBw
YWlyIHRoYXQgd2UgaGF2ZSBhc3NvY2lhdGVkLCBidXQgYnkgbWFraW5nIHRoZSB0YWJsZSBV
Q0QgYSBtdWx0aXBsZXQgd2UgaGF2ZSBub3QgaW1wbGllZCB0aGF0IHRoZSB0d28gc291cmNl
cyBpbiBlYWNoIHJvdyBuZWNlc3NhcmlseSByZWZlciB0byB0aGUgc2FtZSBvYmplY3QuICBO
b3RlIHRoYXQgd2UgY2Fubm90IGZpbmQgYSCRbWFpbpIgcG9zaXRpb24gZm9yIHRoaXMgdGFi
bGUuICBUaGlzIGlzIGdvb2QuICBJbiB0aGlzIHNpdHVhdGlvbiB3ZSBkb26SdCByZWFsbHkg
a25vdyB3aGF0IHRoZSBjb3JyZWN0IHBvc2l0aW9uIGlzLiAgU3RydWN0dXJlIHNob3VsZCBu
b3QgbWFudWZhY3R1cmUgaW5mb3JtYXRpb24gdGhhdCBkb2VzIG5vdCBleGlzdCBhbmQgaXQg
aXMgaW1wb3J0YW50IHRoYXQgdGhlIHN0cnVjdHVyZSBhbGxvd3MgdXMgdG8gcHJlc2VydmUg
dGhhdCBhbWJpZ3VpdHkuDQ1JZiB3ZSBiZWxpZXZlIHRoYXQgdGhlIGNyb3NzLW1hdGNoIGlz
IG1hdGNoaW5nIGRhdGEgZnJvbSB0aGUgc2FtZSBvYmplY3Qgd2UgbWlnaHQgaGF2ZSB3cml0
dGVuIGRhdGEgaW4gYSB0YWJsZSB3aXRoIGEgVUNEVHJlZQ0Nc3JjLmluc3RhbmNlDQltZXRh
LmlkO3ZhbHVlCQkJVGhlIFNsb2FuIElEDQlwb3M7aW5zdGFuY2UJCQlUaGUgU2xvYW4gcG9z
aXRpb24gKHRoZSBhY3R1YWwgY29sdW1ucyBhcmUgc3VwcHJlc3NlZCkNCXBob3QuZmx1eDtl
bS5vcHRpY2FsO3ZhbHVlCUEgU2xvYW4gRmx1eAkJDQlzcmMuaW5zdGFuY2UNCQltZXRhLmlk
O3ZhbHVlCQlUaGUgMk1BU1MgSUQNCQlwb3MuaW5zdGFuY2UJCVRoZSAyTUFTUyBwb3NpdGlv
bg0JCXBoeXMuZGVncmVlczt2YWx1ZQlUaGUgb2Zmc2V0IGJldHdlZW4gdGhlIHR3byB0YXJn
ZXRzDQlwaG90LmZsdXg7ZW0uaW5mcmFyZWQ7dmFsdWUJVGhlIDJNQVNTIGZsdXgNDUFzaWRl
IGZyb20gbW92aW5nIHRoZSBvZmZzZXQgY29sdW1uIHdlIGhhdmVuknQgY2hhbmdlZCB0aGUg
ZGF0YSBpbiB0aGUgdGFibGUgYXQgYWxsLiAgSG93ZXZlciB0aGUgdGFibGUgbm93IGluZGlj
YXRlcyB0aGF0IGVhY2ggcm93IGNvbnRhaW5zIGRhdGEgYWJvdXQgYSBzaW5nbGUgc291cmNl
LiAgVGhlIFNsb2FuIElEIGFuZCBwb3NpdGlvbiBhcmUgbm93IHRoZSCRbWFpbpIgbmFtZSBh
bmQgaWQuICBUaGUgMk1BU1MgaW5mb3JtYXRpb24gaXMgcmV0YWluZWQsIGJ1dCBvdGhlciB0
aGFuIHRoZSBmbHV4IHZhbHVlIGl0IGlzIGNvbnNpZGVyZWQgc3Vic2lkaWFyeSB0byB0aGUg
U2xvYW4uICBUaGUgc29mdHdhcmUgdGhhdCBoYXMgZG9uZSB0aGUgY3Jvc3MtY29ycmVsYXRp
b24gaGFzIHJlc29sdmVkIHRoZSBhbWJpZ3VpdGllcyB0aGF0IGFyaXNlIGluIHRoZSBjcm9z
cy1tYXRjaC4NDQ0NDQ1FeGFtcGxlIDUuICBDcm9zcy1jb3JyZWxhdGluZyBzb3VyY2VzIGFu
ZCBvYnNlcnZhdGlvbnMuDUEgZ2VuZXJpYyBjcm9zcy1jb3JyZWxhdG9yIG1pZ2h0IGJlIGFz
a2VkIHRvIGNvcnJlbGF0ZSBhIHRhYmxlIG9mIG9ic2VydmF0aW9ucyBhbmQgYSB0YWJsZSBv
ZiBzb3VyY2VzLiAgUGVyaGFwcyB0aGUgdXNlciB3YW50cyB0byBmaW5kIHRoZSBzb3VyY2Vz
IHdpdGhpbiB0aGUgZmllbGQgb2YgdmlldyBvZiB0aGUgb2JzZXJ2YXRpb25zLCBvciBwZXJo
YXBzIHRoZXkgd2lzaCB0byBmaW5kIHRoZSBvYnNlcnZhdGlvbnMgdGhhdCBjb250YWluIGEg
c291cmNlLiAgV2l0aG91dCBrbm93bGVkZ2Ugb2Ygd2hhdCB0aGUgdXNlciB3YW50cyB0aGUg
Y29ycmVsYXRvciBtaWdodCBwcm9kdWNlIGEgVUNEVHJlZSBsaWtlDQ1jb25jZXB0O211bHRp
cGxldA0Jb2JzLmluc3RhbmNlDQkJhSBvYnNlcnZhdGlvbiBmaWVsZHMNCXNyYy5pbnN0YW5j
ZQ0JCYUgc3JjIGZpZWxkcw0NTm90ZSB0aGUgdXNlIG9mIGNvbmNlcHQgaW4gdGhlIHRhYmxl
IFVDRC4gIEdpdmVuIG1vcmUgaW5wdXQgYWJvdXQgdGhlIHVzZXIgd2FudHMsIHRoZSBjb3Jy
ZWxhdG9yIG1pZ2h0IGhhdmUgY2hvc2VuIGVpdGhlciBzcmMuaW5zdGFuY2Ugb3Igb2JzLmlu
c3RhbmNlIGFzIHRoZSBiYXNpYyB0eXBlIG9mIHRoZSB0YWJsZS4NDUluIHRoZSBkaXNjdXNz
aW9uIG9mIHRoZSBsYXN0IGZldyBleGFtcGxlcyBhYm92ZSB3ZSBiZWdhbiBhYmJyZXZpYXRp
bmcgVUNEVHJlZXMgYnkgbm90IGluY2x1ZGluZyBldmVyeSBjb2x1bW4gYnV0IGp1c3QgaW5j
bHVkaW5nIHRoZSBncm91cCBwYXJhbWV0ZXJzIGluIHNvbWUgcGxhY2VzLiAgVGhpcyBpbGx1
c3RyYXRlcyBhbm90aGVyIGFzcGVjdCBvZiB0aGUgZmxleGliaWxpdHkgb2YgdGhlIFVDRFRy
ZWUgaW4gZGVzY3JpYmluZyB0aGUgdGFibGUgc3RydWN0dXJlLiAgV2UgbmVlZG6SdCBjbHV0
dGVyIHRoZSBkaXNjdXNzaW9uIG9mIG91ciBkYXRhIG1vZGVscyB3aXRoIGlycmVsZXZhbnQg
ZGV0YWlscywgZS5nLiwgd2UgY2FuIHRhbGsgYWJvdXQgcG9zaXRpb25zIHdpdGggaGF2aW5n
IHRvIHNwZWNpZnkgdGhlIGRldGFpbGVkIGNvbHVtbnMuICBXZSBjYW4ganVzdCBhcyBlYXNp
bHkgbWF0Y2ggYSBwb3NpdGlvbiBzcGVjaWZpZWQgaW4gZ2FsYWN0aWMgY29vcmRpbmF0ZXMg
YXMgb25lIHNwZWNpZmllZCBpbiBSQSBhbmQgRGVjLg0NNS4xLiAgVUNEVHJlZXMgYW5kIERh
dGEgTW9kZWxzDVN0YW5kYXJkIGlkaW9tcyBmb3IgdGhlIHN0cnVjdHVyZSBvZiB0YWJsZXMg
c2hvdWxkIGJlIGRldmVsb3BlZCBhcyBzb29uIGFzIHRoZSBuZXcgVUNEIHNjaGVtZSBhbmQg
Vk9UYWJsZSBncm91cGluZyBlbmhhbmNlbWVudHMgYXJlIGF2YWlsYWJsZS4gICBJZiB0YWJs
ZXMgdXNlIHRoZSBncm91cGluZyBzdHJ1Y3R1cmVzIGluIGNvbnNpc3RlbnQgZmFzaGlvbnMs
IHRoZW4gVUNEVHJlZXMgbWF5IGJlIHVzZWQgaW4gZGVmaW5pbmcgZGF0YSBtb2RlbHMgYXQg
bGVhc3QgYXMgdGhleSByZWxhdGUgdG8gdGFidWxhciBkYXRhLiAgU2luY2UgbW9zdCBjb21t
b24gaGlnaC1sZXZlbCBkYXRhdHlwZXMgY2FuIGJlIHJlcHJlc2VudGVkIGluIGEgbnVtYmVy
IG9mIGRpZmZlcmVudCB3YXlzLCBkYXRhIG1vZGVscyB3aWxsIGxpa2VseSBuZWVkIHRvIHNw
ZWNpZnkgbXVsdGlwbGUgcG9zc2libGUgc3RydWN0dXJlcywgYnV0IHRoZSB3aXRoIHRoZSBk
ZXZlbG9wbWVudCBvZiB0b29scyBzcGVjaWZpY2FsbHkgaW50ZW5kZWQgZm9yIHdpbmtsaW5n
IGNvbW1vbmFsaXR5IGhpZGRlbiB3aXRoaW4gY29tcGxleCBYTUwgc3RydWN0dXJlcywgbm90
YWJseSBYUXVlcnksIGl0IG1heSBiZSBwb3NzaWJsZSB0byBidWlsZCB0b29scyB0aGF0IHNl
ZSBpZiB0YWJsZXMgY2FuIGJlIHVzZWQgYXMgc3BlY3RyYSwgdGltZXNlcmllcywgaW1hZ2Vz
IGFuZCBzbyBmb3J0aC4gIEV2ZW4gaWYgdGhpcyBhbWJpdGlvdXMgZ29hbCBjYW5ub3QgYmUg
bWV0LCB0aGUgc3RydWN0dXJpbmcgb2YgdGFibGVzIGFsbG93cyBkYXRhIG1vZGVscyB0byB1
bmFtYmlndW91c2x5IGZpbmQgcmVxdWlyZWQgaW5mb3JtYXRpb24sIGUuZy4sIHRoZSBlcnJv
ciBhc3NvY2lhdGVkIHdpdGggcG9zaXRpb24gb3IgZmx1eCBvciB0aGUgcmVmZXJlbmNlIGZy
YW1lIHBhcmFtZXRlcnMgYXNzb2NpYXRlZCB3aXRoIGEgZ2l2ZW4gbWVhc3VyZW1lbnQgd2hl
biB0aGVyZSBhcmUgc2V2ZXJhbCByZWZlcmVuY2UgZnJhbWVzIHVzZWQgd2l0aGluIHRoZSB0
YWJsZS4NVW5saWtlIFVDRHMgd2hlcmUgaXQgc2VlbXMgcmVhc29uYWJsZSB0byBzdHJpdmUg
Zm9yIGEgc3ludGF4IHRoYXQgbGFyZ2VseSBlbnN1cmVzIHRoZSB1bmlxdWVuZXNzIG9mIHRo
ZSBhcHByb3ByaWF0ZSBVQ0RzLCBpdCBzZWVtcyB1bmxpa2VseSB0aGF0IHRoZXJlIGlzIGFu
eSBuYXR1cmFsIHdheSB0byBlbnN1cmUgdW5pcXVlIHRhYmxlIHN0cnVjdHVyZXMgZm9yIGNv
bXBsZXggZGF0YS4gIFRoZSBwdWJsaWNhdGlvbiBvZiBzdGFuZGFyZCBVQ0RUcmVlcyBvciBv
dGhlciBzdHJ1Y3R1cmUgdGVtcGxhdGVzIHdpbGwgYmUgYmUgbmVlZGVkIHRvIGVuc3VyZSB0
aGF0IFZPIHNlcnZpY2VzIGNhbiB0cmFuc2xhdGUgZGF0YSBtb2RlbHMgaW50byBhY3Rpb25z
IG9uIHJlYWwgZGF0YS4gDQ0NDQ0NIA1JIGhhdmUgZGVsZXRlZCB0aGUgZXh0ZW5zaXZlIGRl
c2NyaXB0aW9uIG9mIHRoZSBwcmV2aW91cyBzY2hlbWUuICBXaGlsZSB0aGVyZSB3YXMgYSBs
b3Qgb2YgdGV4dCB0aGF0IGlzIHByb2JhYmx5IGNsZWFyZXIgYW5kIG1vcmUgcHJlY2lzZSB0
aGFuIHdoYXQgSSBoYXZlIHdyaXR0ZW4sIEkgd2FudGVkIHRvIGdldCB0aGlzIG5ldyBwcm9w
b3NhbCBvdXQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZSwgYW5kIHRyeWluZyB0byBleHByZXNz
IHdoYXQgSSB3YW50ZWQgdG8gc2F5IGluIHRoZSBjb250ZXh0IG9mIHRoZSBleGlzdGluZyBk
b2N1bWVudCB3YXMgaGFyZGVyIHRoYW4ganVzdCBkb2luZyB0aGluZ3MgZGlyZWN0bHkuICBI
b3dldmVyIEkgd291bGQgYW50aWNpcGF0ZSB0aGF0IGluIGEgZmluYWwgZG9jdW1lbnQgc3Vi
c3RhbnRpYWwgZWxlbWVudHMgbWlnaHQgYmUgcmV0YWluZWQuICBUaGlzIG1hdGVyaWFsIHdh
cyB2ZXJ5IGltcG9ydGFudCBpbiBjbGFyaWZ5aW5nIG15IHRob3VnaHRzIG9uIFVDRHMgZXZl
biB0aG91Z2ggSSBjYW1lIHRvIHNvbWV3aGF0IGRpZmZlcmVudCBjb25jbHVzaW9ucy4NVGhl
IGRpc2N1c3Npb24gb24gdXNlIGNhc2VzIGFuZCBzZWxmLW1hdGNoIGhhcyBiZWVuIGRlbGV0
ZWQuICBTZWxmLW1hdGNoIGlzc3VlcyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGFib3ZlIGFuZCB0
aGUgb2xkIHRleHQgd2hpbGUgZGVmaW5pbmcgdGhlIGlzc3VlcyBzYXlzIG5vdGhpbmcgYWJv
dXQgaG93IHRoZXkgYXJlIHRvIGJlIHJlc29sdmVkLg1JIGhhdmUgZGVsZXRlZCB0aGUgc2Vj
dGlvbiBvbiBzb2Z0d2FyZSBhbmQgc2VydmljZXMuICBJdCB3YXMgcXVpdGUgc2tldGNoeSBh
bnl3YXkgYW5kIEmSbSBub3Qgc3VyZSBpdCBhZGRzIGFueXRoaW5nIHRvIHRoZSBkb2N1bWVu
dC4NNi4gVUNEIFN0ZWVyaW5nIENvbW1pdHRlZQ02LjEgQ3JlYXRpb24gb2YgYSBCb2FyZCBm
b3IgTmV3IFVDRCBXb3JkVGVybXMNV2UgYmVsaWV2ZSB0aGF0IHRoZSBpbmNsdXNpb24gb2Yg
bmV3IFVDRCB3b3JkdGVybXMgbXVzdCBiZSBhIGZsZXhpYmxlIHByb2Nlc3MsIHlldCBjb250
cm9sbGVkLiBUaGUgYmVzdCB3YXkgdG8gYWNjb21wbGlzaCB0aGVzZSB0d28gbmVlZHMgd291
bGQgYmUgdG8gY3JlYXRlIGEgcHJvcGVyIHNjaWVudGlmaWMgYm9hcmQgdGhhdCB3b3VsZCBz
dHVkeSBuZXcgVUNEIHJlcXVpcmVtZW50cyBhbmQsIHdpdGhpbiBhIGdpdmVuIHBlcmlvZCBv
ZiB0aW1lLCBnaXZlIGFuIGFuc3dlciBhcyB0byB3aGV0aGVyIGEgbmV3IFVDRCBtdXN0IG9y
IG11c3Qgbm90IGJlIGluY2x1ZGVkIGluIHRoZSBVQ0Qgc3RhbmRhcmRzLiANVGhlIHVzZSBv
ZiCTbWlzc2lvbi1zcGVjaWZpY5QgbmFtZXNwYWNlcyBoYXMgYmVlbiBhZGRyZXNzZWQgaW4g
bWFueSBvY2Nhc2lvbnMsIGFuZCB3ZSBiZWxpZXZlIHRoYXQgbmFtZXNwYWNlcyBzaG91bGQg
YmUgYXZvaWRlZCBhcyBtdWNoIGFzIHBvc3NpYmxlLiBUaGVyZSBoYXMgYmVlbiBhbiBleGVy
Y2lzZSBpbiByZXZpc2luZyB0aGUgVk9YIHdvcmR0ZXJtcyBmb3IgdGhlIFNJQVAgcHJvdG9j
b2wgYW5kIHRyeWluZyB0byBhc3NpZ24gZXhpc3RpbmcgVUNEcyB0byB0aGVtLCBvciBwcm9w
b3NpbmcgbmV3IFVDRCB3b3JkdGVybXMgZm9yIHRoZSBub24tZXhpc3Rpbmcgb25lcy4gDVRo
ZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgYm9hcmQgd291bGQgY29uc2lzdCBvZiBzdHVkeWlu
ZyB0aGUgY2FzZXMgd2hlcmUgYSBVQ0Qgd29yZHRlcm0gaXMgcHJvcG9zZWQgYW5kIHRvIGZp
Z3VyZSBvdXQgd2hldGhlciB0aGUgcHJvcG9zZWQgd29yZHRlcm0gc2hvdWxkIGJlIGFjY2Vw
dGVkIG9yIHJlamVjdGVkLCBhbmQgaW4gY2FzZSBvZiByZWplY3Rpb24gcmVjb21tZW5kaW5n
IHRoZSBjbG9zZXN0IGV4aXN0aW5nIHdvcmR0ZXJtIHRoYXQgc2hvdWxkIGJlIHVzZWQuDUlu
IGNhc2UgYSBuZXcgd29yZHRlcm0gaXMgYWNjZXB0ZWQgaW50byB0aGUgbWFpbiB0cmVlLCBh
biBpbnRlcm5hbCBwcm9jZWR1cmUgc2hvdWxkIGJlIGVzdGFibGlzaGVkIHNvIHRoYXQgdGhl
IG5ldyBVQ0QgYmVjb21lcyBsaXZlIGFmdGVyIGEgcHJvcGVyIGludGVybmFsIG5ldyByZWxl
YXNlIGluIGEgc2hvcnQgcGVyaW9kIG9mIHRpbWUuDUl0IHNob3VsZCBiZSBhZ3JlZWQgd2hl
dGhlciB0aGlzIGJvYXJkIHdvdWxkIHN0dWR5IHRoZSBwcm9wb3NlZCBjYXNlcyBpbiBhbiCT
b24gZGVtYW5klCBiYXNpcyBvciB3b3VsZCBjb2xsZWN0IHJlcXVlc3RzIGFuZCBzdHVkeSB0
aGVtIG9uIGEgcGVyaW9kaWMgYmFzaXMuDUEgc3VnZ2VzdGlvbiBvbiB0aGUgZm9ybWF0aW9u
IG9mIHRoaXMgc2NpZW50aWZpYyBjb21taXR0ZWUgd291bGQgYmUgdGhhdCBpdCBtaWdodCBj
b250YWluIHBlb3BsZSBmcm9tIENEUyAoYXMgdGhleSBoYXZlIHRoZSBleHBlcmllbmNlIGFu
ZCB0aGUgcmVzb3VyY2VzKSBidXQgaXQgc2hvdWxkIGJlIG9mZmVyZWQgdG8gYWxsIHJlbGV2
YW50IHBhcnRpZXMuIEl0IHdvdWxkIGFsc28gYmUgdmVyeSBpbXBvcnRhbnQgdG8gaGF2ZSBh
IG1lbWJlciBmcm9tIHRoZSBkYXRhIHByb3ZpZGVycyBjb21tdW5pdHksIGFzIHRoZSBzY2ll
bnRpc3RzIHZpZXcgb24gc29tZSBpc3N1ZXMgbWlnaHQgbm90IGluY2x1ZGUgb3RoZXIgaW1w
b3J0YW50IHZpZXdzIGZyb20gZGF0YSBwcm92aWRlcnMuDTYuMiBBIHByb2NlZHVyZSB0byBy
ZXF1ZXN0IG5ldyBVQ0Qgd29yZHRlcm1zDUEgcHJvY2VkdXJhbCBkb2N1bWVudCBzaG91bGQg
YmUgY3JlYXRlZCB0byBtYWtlIGl0IGVhc3kgdG8gYSB1c2VyIHRvIGFzayBmb3IgYSBuZXcg
VUNEIGFuZCB0byB1bmRlcnN0YW5kIHRoZSBpbXBsaWNhdGlvbnMgb2YgZG9pbmcgc28uIFRo
aXMgZG9jdW1lbnQgd291bGQgYWRkcmVzczoNdGhlIGNvbnRhY3QgcG9pbnQgdG8gYXNrIGZv
ciBuZXcgVUNEDXRoZSBsaWZlLWN5Y2xlIG9mIHRoZSBwcm9jZXNzIG9mIGFza2luZyBmb3Ig
YSBuZXcgVUNEDXdoZW4gYW5kIGhvdyBhIG5ldyBVQ0QgYmVjb21lcyBsaXZlDXdoYXQgdG8g
ZG8gaWYgYSBVQ0QgaXMgcmVqZWN0ZWQNVGhpcyB0eXBlIG9mIGFjdGlvbnMgY291bGQgKGFu
ZCBzaG91bGQpIGJlIHN1cHBvcnRlZCBieSB0b29scyBsaWtlIGFuIGF1dG9tYXRpYyBmb3Jt
IHRoYXQgaXMgZmlsbGVkIGluIGFuZCBzZW50IHRvIHRoZSBzY2llbnRpZmljIGJvYXJkLCBn
aXZpbmcgYW4gYW5zd2VyIGJhY2sgdG8gdGhlIHVzZXIgYWNrbm93bGVkZ2luZyB0aGUgcmVx
dWVzdCwgYW5kIGdpdmluZyBhIHRpbWUgZXN0aW1hdGUgZm9yIGFuIGFuc3dlci4gQWxsIHRo
ZXNlIGlzc3VlcyB3aWxsIGJlIHN1Z2dlc3RlZCBpbiBhIHNlcGFyYXRlIHBvaW50Lg1MZXNz
b25zIHNob3VsZCBiZSBsZWFybnQgZnJvbSBvdGhlciBwcm9qZWN0cyB3aGVyZSBzaW1pbGFy
IGJvYXJkcyBleGlzdC4gVGhlcmUgc2hvdWxkIGJlIGEgdGhvcm91Z2ggaW52ZXN0aWdhdGlv
biAobWF5YmUgZnJvbSB0aGUgYm9hcmQgbWVudGlvbmVkIGFib3ZlKSBvZiBob3cgb3RoZXIg
cHJvamVjdHMgaGF2ZSB3b3JrZWQgaW4gdGhpcyBkaXJlY3Rpb24gKGxpa2UgdGhlIFBsYW5l
dGFyeSBEYXRhIFN5c3RlbSAoUERTKSwgdGhlIEZJVFMgY29uc29ydGl1bSwgdGhlIFczQykg
YW5kIHRyeSB0byBnZXQgdGhlIHJpZ2h0IHRoaW5ncyBmcm9tIHRoZW0gd2hpbGUgYXZvaWRp
bmcgdGhlIHdyb25nIG9uZXMuDTYuMyBDcmVhdGlvbiBvZiBhIFRlY2huaWNhbCBCb2FyZA1U
aGVyZSBzaG91bGQgYmUgdG9vbHMgYXZhaWxhYmxlIGZvciB0aGUgdXNlciB0byBjaGVjayBm
b3IgdGhlIGV4aXN0ZW5jZSBvZiBVQ0RzLCBldGMuIFNvbWUgb2YgdGhlc2UgdG9vbHMgZXhp
c3QgYWxyZWFkeSBpbiBDRFMsIGFuZCB0aGV5IGFyZSBnb29kIGNhbmRpZGF0ZXMgdG8gYmVj
b21lIHRoZSBzb3J0IG9mIJNvZmZpY2lhbJQgdG9vbHMgZm9yIHRoZSBVQ0Qgc3RhbmRhcmRz
LiBIb3dldmVyLCB3ZSBmZWVsIGl0IGlzIG5lY2Vzc2FyeSB0byBoYXZlIGEgcHJvcGVyIHRl
Y2huaWNhbCBib2FyZCB0aGF0IGNvdWxkLCBldmVudHVhbGx5LCBkZWNpZGUgb24gd2hhdCB0
b29scyBhcmUgcmVhbGx5IG5lY2Vzc2FyeSB0byBtYWtlIHRoZSBVQ0Qgd29yayBmZWFzaWJs
ZSBhbmQgYXMgZWFzeSBhcyBwb3NzaWJsZSBmb3IgdGhlIHVzZXIuIFRoaXMgYm9hcmQgd291
bGQgYmUgbWFpbmx5IGluIGNoYXJnZSBvZiB3cml0aW5nIHByb3BlciByZXF1aXJlbWVudHMg
Zm9yIHRoZSB0b29scy4gVGhlIG1hbmFnZW1lbnQgb2YgcmVzb3VyY2VzLCBldGMuLCBzaG91
bGQgYmUgaGFuZGxlZCBieSB0aGUgY29uY2VwdHMgd2FudGluZyB0byB3b3JrIGZvciB0aGUg
Vk8gcHJvamVjdCwgYnV0IHRoZSBkZWZpbml0aW9ucyBvZiByZXF1aXJlbWVudHMsIGV0Yy4s
IHNob3VsZCBiZSBjZW50cmFsaXplZCBvbiB0aGlzIGJvYXJkLg02LjMgQ29udGFjdCBwb2lu
dCBmb3IgVUNEIGlzc3Vlcw1XZSBmZWVsIHRoZSBuZWNlc3NpdHkgdG8gY3JlYXRlIGEgY29u
dGFjdCBwb2ludCB0byB3aGljaCBhbGwgVUNEIHJlbGF0ZWQgbWF0dGVycyBjYW4gYmUgYWRk
cmVzc2VkLiBUaGlzIGNvbnRhY3QgcG9pbnQgY291bGQgYmUgYSB3ZWIgYWRkcmVzcyBkZXZv
dGVkIGV4cGxpY2l0bHkgdG8gdGhhdCBpbiB0aGUgY29udGV4dCBvZiB0aGUgVk8sIGEgcHJv
cGVybHkgb3JnYW5pemVkIHdlYiBwbGFjZSwgd2hlcmUgYWxsIHRoZSB0b29scyB3b3VsZCBi
ZSBhdmFpbGFibGUsIGFzIHdlbGwgYXMgYWxsIGRvY3VtZW50cyBhbmQgcHJvY2VkdXJlcyBm
b3IgY3JlYXRpb24gb2YgbmV3IFVDRCB3b3JkdGVybXMsIGV0Yy4sIHdpdGggcHJhY3RpY2Fs
IGV4YW1wbGVzIGFuZCB0aGUgbGlrZS4gDUFwcGVuZGl4IDEuDVRoZXJlIGhhcyBiZWVuIG11
Y2ggZGViYXRlIGluIHRoZSBVQ0QgZm9ydW0gb3ZlciBkaXZpc2lvbiBvZiB0aGUgZWxlY3Ry
b21hZ25ldGljIHNwZWN0cnVtLCBzaW5jZSB0aGlzIGlzIHdoZXJlIHRoZSBxdWFsaXRhdGl2
ZSBhbmQgdGhlIHF1YW50aXRhdGl2ZSBtZWV0LiBJZiB3ZSBwdXQgZXZlcnkgd29yZHRlcm0g
YWJvdXQgc3BlY3RydW0gY292ZXJhZ2UgaW50byB0aGUgVUNELCB0aGVyZSB3b3VsZCBiZSBo
dW5kcmVkcyBvZiB0ZXJtcywgdGhlcmVmb3JlIHdlIGhhdmUgY2hvc2VuIHRvIGtlZXAgdG8g
YSByYXRpb25hbCBkaXZpc2lvbiAoYmVsb3cpIHBsdXMgYSB2ZXJ5IGZldyBzcGVjaWFsIHdv
cmR0ZXJtcy4NVGhlIHdhdmVsZW5ndGggc3BlY3RydW0gaXMgZmlyc3QgZGl2aWRlZCBpbiB0
aGUgNyBjbGFzc2ljYWwgZG9tYWlucyByYWRpbyAvIElSIC8gT3B0aWNhbCAvIFVWIC8gRVVW
IC8gWC1yYXkgLyBnYW1tYS4gRnVydGhlciBkaXZpc2lvbnMgYXJlIG1hZGUgdG8gZGVmaW5l
IHRoZSBsYXJnZSBiYW5kcyBjbGFzc2ljYWxseSB1c2VkIGluIG9wdGljYWwgLyBJUiAvIFVW
LCBhbmQgaW4gcmFkaW8gZnJlcXVlbmNpZXMgd2Uga2VlcCBiYW5kcyBzcGFjZWQgYnkgYSBm
YWN0b3IgMi4gSW4gRmlndXJlIDMsIGEgc3BlY2lhbCB3b3JkIGlzIHRoZXJlIGZvciBIYWxw
aGEgYXMgYSBzdWJjbGFzcyBvZiBvcHQuUi4gSWYgYSBkZXNpcmVkIGJhbmQgZG9lcyBub3Qg
Zml0IGluIHRoZSByYXRpb25hbCBsaXN0LCBpdCBpcyByZWNvbW1lbmRlZCB0byB1c2UgdGhl
IHNtYWxsZXN0IGVuY2xvc2luZyBiYW5kLg0BDUZpZ3VyZSATIFNFUSBGaWd1cmUgXCogQVJB
QklDIBQxFTogSGllcmFyY2hpY2FsIG9yZ2FuaXphdGlvbiBvZiB0aGUgZWxlY3Ryb21hZ25l
dGljIHNwZWN0cnVtLiBUaGUgc3RhbmRhcmQgYmFuZHMgYXJlIHJlcHJlc2VudGVkIGluIGJs
YWNrLiBUaGUgc3VnZ2VzdGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBub24tc3RhbmRhcmQgYmx1
ZSByYW5nZXMgaXMgc2hvd24gaW4gYmx1ZTogaW4gZWFjaCBjYXNlLCB3ZSB1c2UgdGhlIHNt
YWxsZXN0IGVuY2xvc2luZyBzdGFuZGFyZCBiYW5kLg1UaGUgb3ZlcmFsbCBsaXN0IGlzIGFz
IGZvbGxvd3M6IA0NDQ1VQ0QgZGVzaWduYXRpb24HTGFtYmRhB0ZyZXEHRW5lcmd5IAdOb3Rl
cwcHUmFkaW8gUmVnaW1lBwdlbS5yYWRpby4yMC0xMDBNSHogBz4zbSAHPDEwME1IeiAHoAeg
BwdlbS5yYWRpby4xMDAtMjAwTUh6IAcxLjUtM20gBzEwMC0yMDBNSHoHoAegBwdlbS5yYWRp
by4yMDAtNDAwTUh6IAc3NS0xNTBjbSAHMjAwLTQwME1IegegB6AHB2VtLnJhZGlvLjQwMC03
NTBNSHogBzQwLTc1Y20gBzQwMC03NTBNSHoHoAegBwdlbS5yYWRpby43NTAtMTUwME1IeiAH
MjAtNDBjbSAHNzUwLTE1MDBNSHoHoAegBwdlbS5yYWRpby4xNTAwLTMwMDBNSHoHMTAtMjBj
bSAHMS41LTNHSHogB6AHoAcHZW0ucmFkaW8uMy02R0h6IAc1LTEwY20gBzMtNkdIeiAHoAeg
BwdlbS5yYWRpby42LTEyR0h6IAcyLjUtNWNtIAc2LTEyR0h6IAegB6AHB2VtLnJhZGlvLjEy
LTI1R0h6IAcxLjItMi41Y20gBzEyLTI1R0h6IAegB6AHB2VtLnJhZGlvLjI1LTUwR0h6IAc2
LTEybW0gBzI1LTUwR0h6IAegB6AHB2VtLnJhZGlvLjUwLTEwMEdIeiAHMy02bW0gBzUwLTEw
MEdIeiAHoAegBwdlbS5yYWRpby4xMDAtMjAwR0h6IAcxLjUtM21tIAcxMDAtMjAwR0h6B6AH
oAcHZW0ucmFkaW8uMjAwLTQwMEdIeiAHNzUwLTE1MDC1bSAHMjAwLTQwMEdIegegB6AHB2Vt
LnJhZGlvLjQwMC03NTBHSHogBzQwMC03NTC1bSAHNDAwLTc1MEdIegegB6AHB2VtLnJhZGlv
Ljc1MC0xNTAwR0h6IAcyMDAtNDAwtW0gBzc1MC0xNTAwR0h6B6AHQ09CRSAyNDC1bQcHZW0u
cmFkaW8uMTUwMC0zMDAwR0h6BzEwMC0yMDC1bSAHMTUwMC0zMDAwR0h6B6AHQ09CRSAxNDC1
bQcHSW5mcmEtUmVkIFJlZ2ltZQcHZW0uSVIuNjAtMTAwdW0HNjAtMTAwtW0gBzMtNVRIeiAH
oAdJUkFTIDEwMLVtBwdlbS5JUi4zMC02MHVtIAczMC02MLVtIAc1LTEwVEh6IAegB0lSQVMg
NjC1bSAHB2VtLklSLjE1LTMwdW0HMTUtMzC1bSAHMTAtMjBUSHogB6AHSVJBUyAyNbVtBwdl
bS5JUi44LTE1dW0HOC0xNbVtIAcyMC0zNy41VEh6IAegB04gYmFuZDsgSVJBUyAxMrVtBwdl
bS5JUi40LTh1bSAHNC04tW0gBzM3LjUtNzVUSHogB6AHTSBiYW5kOyBCcnthbHBoYX09NDA1
MW5tIAcHZW0uSVIuMy00dW0gBzMtNLVtIAcxMDAtMTUwVEh6IAegB0wsIEwnLCBMJycHB2Vt
LklSLksgBzItM7VtIAc3NS0xMDBUSHogB6AHSyBiYW5kBwdlbS5JUi5IIAcxLjUtMi4wtW0g
BzIwMC0zMDBUSHogB6AHSCBiYW5kOyBQYXthbHBoYX09MTg3NW5tLCBCcntMaW1pdH09MTcz
MW5tBwdlbS5JUi5KIAcxLjAtMS41tW0gBzE1MC0yMDBUSHogB6AHSiBiYW5kOwcHT3B0aWNh
bCBSZWdpbWUHB2VtLm9wdC5JBzc1MC0xMDAwbm0gBzMwMC00MDBUSHogBzEuMi0xLjZlViAH
SSBiYW5kOyBQYXtMaW1pdH09ODIwbm0HB2VtLm9wdC5SBzYwMC03NTBubSAHNDAwLTUwMFRI
eiAHMS42LTIuMGVWIAdSIGJhbmQ7IEhhbHBoYT02NTZubSAHB2VtLm9wdC5WIAc1MDAtNjAw
bm0gBzUwMC02MDBUSHogBzIuMC0yLjRlViAHViBiYW5kOyAHB2VtLm9wdC5CIAc0MDAtNTAw
bm0gBzYwMC03NTBUSHogBzIuNC0zLjBlViAHQiBiYW5kOyBIe2JldGF9PTQ4Nm5tLCBIe2dh
bW1hfT00MzRubSwgSHtkZWx0YX09NDEwbm0gBwdlbS5vcHQuVSAHMzAwLTQwMG5tIAc3NTAt
MTAwMFRIeiAHMy4wLTQuMGVWIAdVIGJhbmQ7IEJhSnVtcD0zNjVubQcHVWx0cmEtVmlvbGV0
IFJlZ2ltZQcHZW0uVVYuMjAwLTMwMG5tIAcyMDAtMzAwbm0gBzEwMDAtMTUwMFRIeiAHNC02
ZVYgB1VWMSBiYW5kIAcHZW0uVVYuMTAwLTIwMG5tIAcxMDAtMjAwbm0gBzE1MDAtMzAwMFRI
eiAHNi0xMmVWIAdVVjIgYmFuZDsgTHl7YWxwaGF9PTEyMS42bm0gBwdFeHRyZW1lIFVsdHJh
LVZpb2xldCBSZWdpbWUHB2VtLkVVVi41MC0xMDBubSAHNTAtMTAwbm0gBzMtNlBIeiAHMTIt
MjRlViAHTHl7TGltaXR9PTkxLjJubQcHZW0uRVVWLjEwLTUwbm0gBzEwLTUwbm0gBzYtMzBQ
SHoHMjQtMTIwZVYHoAcHWC1yYXkgUmVnaW1lBwdlbS5YLXJheS5zb2Z0IAc2LTEwMMUHMzAt
NTAwUEh6IAcwLjEyLTJrZVYgB6AHB2VtLlgtcmF5LmhhcmQgBzAuMS02xQcwLjUtMzBFSHog
BzItMTJrZVYgB6AHB0dhbW1hIFJlZ2ltZQcHZW0uZ2FtbWEuc29mdCAHMC4yNS0xMHBtIAcz
MC0xMjAwRUh6IAcxMi01MDBrZVYgB6AHB2VtLmdhbW1hLmhhcmQgBzwyNTBmbSAHPiAxMjAw
RUh6IAc+NTAwa2VWIAdlKy9lLSAHBwwNE1BBR0UgIBUNDQ0TUEFHRSAgFDYVDQkJDQ0NDQkT
IFBBR0UgFDIxFQkNDQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAQgAACEJAAAjCQAAQQkAAGUJAAAECgAAIAoAACwK
AACECgAAhwoAAIgKAACKCgAArgoAALcKAAC8CgAAvQoAAL4KAAC/CgAA0goAANcKAADZCgAA
2goAANwKAADdCgAA8AoAAPEKAAD0CgAA9QoAAPYKAAD9CgAA/woAAAALAAACCwAABAsAAA0L
AAAOCwAADwsAAPTp4enZ6eHp4enOysbKwsbKu6+rp6ujlIuDe3Nrg3Njc4OLyl8ABhZoZRcF
AAAOFmjCa30AT0oCAFFKAgAADhZo3CItAE9KAgBRSgIAAA4WaFBuKQBPSgIAUUoCAAAOFmjj
RNYAT0oCAFFKAgAADhZosUpmAE9KAgBRSgIAABEWaLFKZgA1CIFPSgIAUUoCABwVaONE1gAW
aLFKZgA1CIFCKgpDSiAAcGgAgIAAAAYWaBRHHQAABhZowmt9AAAGFmjjRNYAABYWaLFKZgA1
CIFCKgpDSiAAcGgAgIAAAAwVaKd/0gAWaLFKZgAABhZoQhGiAAAGFmjcIi0AAAYWaLFKZgAA
FQNqAAAAABVoWS85ABZosUpmAFUIAQ8WaFsDJQBCKgZwaP8AAAAPFmjveuQAQioGcGj/AAAA
FRVoD0KsABZo3CItAEIqBnBo/wAAABUVaA9CrAAWaLFKZgBCKgZwaP9mAAAAJQAGAAABCAAA
hgoAAIcKAACJCgAAigoAAK8KAAC+CgAAvwoAANIKAADdCgAABAsAAA0LAAAdDgAAJg4AALcP
AAC4DwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPQAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA
9AAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACkAAAAAAAAAAAAAAAApAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA
Z2TjRNYARgEARcaAAQABAGWyemYBAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZKd/0gAABBsAZ2TjRNYAAAEAAAAB
JgAAARsAAAQAAGdkp3/SAAAQAAYAAFTiAACB4gAAg+IAAP39/QAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQMPCwAAFwsAAB8L
AAAgCwAAIQsAACILAABQCwAAUQsAAFILAABtCwAAbgsAAHALAAB3CwAAewsAAHwLAAB9CwAA
fgsAAKcLAACoCwAAqQsAAL8LAADACwAAwgsAAMYLAADKCwAAywsAAMwLAADNCwAA7QsAAO4L
AADvCwAA/AsAAP0LAAD/CwAADQwAABUMAAAWDAAAFwwAABgMAABADAAAQQwAAEIMAABXDAAA
WAwAAFoMAABjDAAAawwAAGwMAABtDAAAbgwAAJQMAACVDAAAlgwAAPz3/PHn/Nrn8dLx/Pf8
8ef8xefx0vH89/zx5/y45/HS8fz3/PHn/Kvn8dLxp6KnnJKnhZIAABkCCIEDahggAgAGCAEW
aNwiLQBDShIAVQgBEwNqAAAAABZo3CItAENKEgBVCAEKFmjcIi0AQ0oSAAAJFmjcIi0ANQiB
BhZo3CItAAAZAgiBA2ptHwIABggBFmixSmYAQ0oSAFUIARkCCIEDatIeAgAGCAEWaLFKZgBD
ShIAVQgBGQIIgQNqJR4CAAYIARZosUpmAENKEgBVCAEPA2oAAAAAFmixSmYAVQgBGQIIgQNq
bh0CAAYIARZosUpmAENKEgBVCAETA2oAAAAAFmixSmYAQ0oSAFUIAQoWaLFKZgBDShIAAAkW
aLFKZgA1CIEGFmixSmYANJYMAACpDAAAqgwAAKwMAACzDAAAuAwAALoMAAC8DAAA1gwAANgM
AADcDAAA3QwAAOEMAADrDAAA7AwAAO0MAADuDAAAHA0AAB0NAAAeDQAAOQ0AADoNAAA8DQAA
Qg0AAEcNAABIDQAASQ0AAEoNAABwDQAAcQ0AAHINAACFDQAAhg0AAIgNAACMDQAAkQ0AAJIN
AACTDQAAlA0AALgNAAC5DQAAug0AAMsNAADMDQAAzg0AANINAADaDQAA2w0AANwNAADdDQAA
BA4AAPry+u7m3trU+tDM0MfQwbfQqrfBosHQx9DBt9CVt8GiwdDH0MG30Ii3waLB0MfQwbfQ
AAAAAAAAAAAAAAAAAAAAAAAAGQIIgQNqHSICAAYIARZosUpmAENKEgBVCAEZAgiBA2p2IQIA
BggBFmixSmYAQ0oSAFUIAQ8DagAAAAAWaLFKZgBVCAEZAgiBA2q/IAIABggBFmixSmYAQ0oS
AFUIARMDagAAAAAWaLFKZgBDShIAVQgBChZosUpmAENKEgAACRZosUpmADUIgQYWaGUXBQAA
BhZosUpmAAAKFmgURx0AQ0oSAAAGFmgURx0AAA8VaBRHHQAWaBRHHQA1CIEPFWgURx0AFmjc
Ii0ANQiBBhZo3CItAAAPA2oAAAAAFmjcIi0AVQgBChZo3CItAENKEgAyBA4AAAUOAAAGDgAA
Gg4AABsOAAAcDgAAHQ4AACYOAAApDgAAsw4AALYOAAC5DgAAIg8AAEEPAABCDwAARw8AAEgP
AAC2DwAAtw8AALgPAADPDwAA0A8AAOAPAAD3DwAAUhAAAHMQAAAWEQAAFxEAAEERAABCEQAA
QxEAAH0RAAB+EQAArhEAALARAADPEgAA8uji2uLUzcnFsqjFpMmgssXJnM2VyZHJxcmByW6B
ydrJZl4AAAAAAAAAAAAOFmj6VSQAbUgJAHNICQAADhZosUpmAG1ICQBzSAkAACQCCIEDamkj
AgAGCAEWaLFKZgA2CIFDShYAT0oCAFFKAgBVCAEAHgNqAAAAABZosUpmADYIgUNKFgBPSgIA
UUoCAFUIAQAGFmhQbikAAAwVaFBuKQAWaLFKZgAABhZo+lUkAAAGFmgURx0AAAYWaNZPHAAA
EwEIgQRIAQAFaGWyemYWaMtpbQAlAAiBFmgPQqwAF2jLaW0AY0gBAGRoAAAAAGRoAAAAAGRo
ZbJ6ZgYWaA9CrAAABhZosUpmAAAMFWinf9IAFmixSmYAAAoWaNwiLQBDShIAAA8DagAAAAAW
aLFKZgBVCAEKFmixSmYAQ0oSAAATA2oAAAAAFmixSmYAQ0oSAFUIARkCCIEDasAiAgAGCAEW
aLFKZgBDShIAVQgBACO4DwAA0A8AALARAACxEQAAHxMAADATAACOEwAAjxMAANUTAADnFgAA
6BYAALkAAAAAAAAAAAAAAAC3AAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAALIAAAAAAAAAAAAA
AABsAAAAAAAAAAAAAAAAZwAAAAAAAAAAAAAAAGcAAAAAAAAAAAAAAABfAAAAAAAAAAAAAAAA
twAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAEACiYAC0YAAGdk
D0KsAAAEAABnZFkvOQBGAQBFxoABAAEAZbJ6ZgEAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAC4AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdk1k8cAAAEAABnZNZP
HAAAAQAARgEARcaAAQABAGWyemYBAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZFBuKQAACs8SAAAfEwAAIBMAADAT
AACNEwAAjhMAAK8TAADUEwAA1RMAACIUAAAmFAAAeBQAALgVAADaFQAA3BUAAN4VAABHFgAA
SxYAAFcWAABlFgAAbxYAAJgWAACZFgAApRYAAKcWAACrFgAAtRYAAOYWAADnFgAAFhcAADYX
AAASGAAAExgAANQYAABMGQAATRkAAF4ZAABgGQAAdBkAAIUZAABJGgAAVBoAAJ4bAAD48erm
4t7q1+be5t7TwLbT5tPmrqqmqqaqnqrTmpaajJqImtOE04jTeoQAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAATAQiBBEgBAAVoa7J6ZhZoy2ltAAYWaPpVJAAABhZo1k8cAAATAQiB
BEgBAAVoabJ6ZhZoy2ltAAYWaBRHHQAABhZo93hNAAAPFWhQbikAFmhQbikANgiBBhZo7G+i
AAAGFmhQbikAAA8VaFBuKQAWaLFKZgA2CIETAQiBBEgBAAVoaLJ6ZhZoy2ltACUACIEWaBsO
OgAXaMtpbQBjSAEAZGgAAAAAZGgAAAAAZGhosnpmBhZoGw46AAAMFWgPQqwAFmgPQqwAAAYW
aA9CrAAABhZop3/SAAAGFmixSmYAAAwVaKd/0gAWaLFKZgAADBVop3/SABZo1k8cAAAOFmjW
TxwAbUgJAHNICQAq6BYAAE0ZAABOGQAAxxkAAN0ZAAAMGgAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAAswAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAEkAAAomAAtGIQBFxoABAAEAZbJ6ZgEAAAAAAAAAAAAEAgAEAgAEAgAAAgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAC4AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkGw46AABJAAAKJgAL
RiEARcaAAQABAGWyemYBAAAAAAAAAAAABAIABAIABAIAAAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAIAAAAuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZBsOOgAAAQAAAAUMGgAASRoAAJIaAADSGgAA
tQAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAAAhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASQAA
CiYAC0YhAEXGgAEAAQBlsnpmAQAAAAAAAAAAAAQCAAQCAAQCAAAFAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAALgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QbDjoAAEkAAAomAAtGIQBFxoABAAEA
ZbJ6ZgEAAAAAAAAAAAAEAgAEAgAEAgAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAgAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAGdkGw46AABJAAAKJgALRiEARcaAAQABAGWyemYBAAAAAAAAAAAA
BAIABAIABAIAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAuAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABnZBsOOgAAA9IaAABRGwAAnhwAAJ8cAAA4HgAAQSAAAEIgAAD+IAAADSEAAH8jAAAyJAAA
tQAAAAAAAAAAAAAAAG4AAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAZwAAAAAAAAAAAAAAAGcA
AAAAAAAAAAAAAABnAAAAAAAAAAAAAAAAZwAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABnAAAA
AAAAAAAAAAAAWgAAAAAAAAAAAAAAAAAAAAAAAAAEAABnZMQQcAAIAQAKJgALRgAAZ2SbIz4A
AAEAAAAEAABnZPpVJAAARgAACiYAC0YhAEXGgAEAAQBlsnpmAQAAAAAAAAAAAAQCAAQCAAQC
AAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAALgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEkAAAom
AAtGIQBFxoABAAEAZbJ6ZgEAAAAAAAAAAAAEAgAEAgAEAgAABgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAgAAAC4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkGw46AAAKnhsAAKgbAACwGwAAuhsAALsb
AAC+GwAAyRsAANwbAAAaHAAAnRwAAJ4cAACfHAAA/RwAAB0dAAAeHQAAHx0AACAdAAAkHQAA
KB0AADAdAAA1HQAAQB0AAEEdAABkHQAAZR0AAJAdAACUHQAAlR0AANYdAAA2HgAANx4AADge
AABBIAAA7OLe1MHe1N69ud61sJ2TtZ2TtYqBtX21fXZvZVtlVLUAAAAADBVoxBBwABZosUpm
AAATAQiBBEgBAAVob7J6ZhZoy2ltABMBCIEESAEABWhusnpmFmjLaW0ADBVoxBBwABZoDDSH
AAAMFWjEEHAAFmhQbikAAAYWaFBuKQAAEBVoUG4pABZoUG4pADBKEwAAEBVoUG4pABZoDDSH
ADBKEwAAEwEIgQRIAQAFaKWyemYWaBYYcgAlAAiBFmixSmYAF2gWGHIAY0gBAGRoAAAAAGRo
AAAAAGRopbJ6ZgkWaLFKZgA2CIEGFmixSmYAAAYWaBsOOgAABhZo/llPAAAlAAiBFmj6VSQA
F2jLaW0AY0gBAGRoAAAAAGRoAAAAAGRobbJ6ZhMBCIEESAEABWhtsnpmFmjLaW0ABhZo+lUk
AAATAQiBBEgBAAVobLJ6ZhZoy2ltACUACIEWaPpVJAAXaMtpbQBjSAEAZGgAAAAAZGgAAAAA
ZGhssnpmACBBIAAAQiAAAGYgAABpIAAA/iAAAAwhAAANIQAALiEAADYhAABQIQAAVSEAAFoh
AABzIQAAfSEAAH8hAACBIQAAhiEAAIohAACLIQAApiEAAKshAACwIQAAsSEAANAhAAD88enx
/OLey962qt6m3uKQhnniYFNJPAAZAQiBBEgBAAVoG7N6ZhVop3/SABZooAAtABMBCIEESAEA
BWgbs3pmFmigAC0AGQEIgQRIAQAFaHuyemYWaO51cwA2CIFdCIExAAiBFWinf9IAFmixSmYA
F2judXMANgiBXQiBY0gBAGRoAAAAAGRoAAAAAGRoe7J6ZhkBCIEESAEABWgZs3pmFWinf9IA
FmigAC0AEwEIgQRIAQAFaBmzemYWaKAALQArAAiBFWinf9IAFmixSmYAF2igAC0AY0gBAGRo
AAAAAGRoAAAAAGRoGbN6ZgYWaMQQcAAAFgEIgQRIAQAFaHuyemYWaO51cwA2CIEAKAAIgRZo
sUpmABdo7nVzADYIgWNIAQBkaAAAAABkaAAAAABkaHuyemYAJQAIgRZosUpmABdo7nVzAGNI
AQBkaAAAAABkaAAAAABkaHeyemYGFmixSmYAAAwVaKd/0gAWaLFKZgAADxZomyM+AEIqBnBo
/wAAABUVaJsjPgAWaJsjPgBCKgZwaP8AAAAGFmibIz4AF9AhAADcIQAA3SEAAN4hAADxIQAA
8iEAAPohAAD8IQAAAyIAAAkiAAAKIgAADSIAADEiAAAyIgAANSIAADkiAAA+IgAAPyIAAEQi
AABjIgAAeCIAAHwiAACAIgAAliIAAPXf1cvBy7ett62jrZmPo4XBe2VeSD5eAAAAAAATAQiB
BEgBAAVon7J6ZhZoFhhyACsACIEVaKd/0gAWaLFKZgAXaBYYcgBjSAEAZGgAAAAAZGgAAAAA
ZGifsnpmDBVop3/SABZosUpmAAArAAiBFWinf9IAFmixSmYAF2igAC0AY0gBAGRoAAAAAGRo
AAAAAGRoG7N6ZhMBCIEESAEABWiIsnpmFmigAC0AEwEIgQRIAQAFaImyemYWaO51cwATAQiB
BEgBAAVoibJ6ZhZooAAtABMBCIEESAEABWiHsnpmFmigAC0AEwEIgQRIAQAFaBqzemYWaKAA
LQATAQiBBEgBAAVoGbN6ZhZooAAtABMBCIEESAEABWgWs3pmFmigAC0AEwEIgQRIAQAFaIiy
emYWaO51cwATAQiBBEgBAAVoerJ6ZhZo7nVzABMBCIEESAEABWgcs3pmFmigAC0AKwAIgRVo
p3/SABZosUpmABdooAAtAGNIAQBkaAAAAABkaAAAAABkaByzemYTAQiBBEgBAAVoG7N6ZhZo
oAAtAAAXliIAAKkiAACvIgAAtSIAALgiAAC6IgAAwCIAAMUiAADOIgAA/yIAAAMjAAAHIwAA
GCMAAE4jAABTIwAAfyMAAPAjAAD5IwAAMSQAADIkAAChJAAAzSQAAM4kAADxJAAA9SQAAPkk
AAALJQAADyUAABMlAAAlJQAAJiUAACclAAAqJQAA/Onf1PzU/NT8wbf8sKewo5+jmKOUkIx5
b4x5b4xljFIlAAiBFmjHX7EAF2h8ClsAY0gBAGRoAAAAAGRoAAAAAGRoarN6ZhMBCIEESAEA
BWhqs3pmFmh8ClsAEwEIgQRIAQAFaIuyemYWaO51cwAlAAiBFmjHX7EAF2judXMAY0gBAGRo
AAAAAGRoAAAAAGRoi7J6ZgYWaMdfsQAABhZolhHjAAAGFmj1aXkAAAwVaJFBVgAWaJFBVgAA
BhZoxBBwAAAGFmixSmYAABAVaFBuKQAWaLFKZgAwShMAAAwVaKd/0gAWaLFKZgAAEwEIgQRI
AQAFaIGyemYWaO51cwAlAAiBFmhbAyUAF2judXMAY0gBAGRoAAAAAGRoAAAAAGRogbJ6ZhUV
aFsDJQAWaFsDJQBCKgZwaP9mAAATAQiBBEgBAAVogLJ6ZhZo7nVzACUACIEWaFsDJQAXaO51
cwBjSAEAZGgAAAAAZGgAAAAAZGiAsnpmBhZoWwMlACAyJAAAoSQAAM0kAADOJAAAqSgAAKoo
AABHKgAAiSoAAIoqAADOKgAAHCsAALUAAAAAAAAAAAAAAABrAAAAAAAAAAAAAAAAZgAAAAAA
AAAAAAAAAGYAAAAAAAAAAAAAAABmAAAAAAAAAAAAAAAAZgAAAAAAAAAAAAAAAGYAAAAAAAAA
AAAAAABmAAAAAAAAAAAAAAAAWQAAAAAAAAAAAAAAAFkAAAAAAAAAAAAAAAAAAAAAAAwAAA+E
4BARhIjwXoTgEGCEiPBnZHZ7IgAABAAAZ2SWEeMAAEkAAAomAAtGCABFxoABAAEAZbJ6ZgAA
AAAAAAAAABcXFxcXFxcXFwAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQC38AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAGdkkUFWAABJAAAKJgALRggARcaAAQABAGWyemYAAAAAAAAAAAAXFxcXFxcX
FxcAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAt/AAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZJFB
VgAACiolAAA1JQAAPiUAAEIlAABGJQAATCUAAFYlAAB/JQAAgiUAALwlAAAhJgAAMyYAAEAm
AACQJgAAsCYAALImAADJJgAA8SYAAAMnAAAKJwAAEicAABcnAAAeJwAAJScAAGUnAABrJwAA
bicAAH4nAACDJwAAjScAAI4nAAD88t/V/MK4/MKlko78ioaC/IZvZYZvZYZaT4ZaT4YAAAAA
FRVoOxBXABZoOxBXAEIqB3Bo/5kAABUVaA0qWAAWaA0qWABCKgZwaP9mAAATAQiBBEgBAAVo
kLJ6ZhZo7nVzACUACIEWaDsQVwAXaO51cwBjSAEAZGgAAAAAZGgAAAAAZGiQsnpmBhZoDSpY
AAAGFmg7EFcAAAYWaJYR4wAABhZoWwMlAAAlAAiBFmhbAyUAF2h8ClsAY0gBAGRoAAAAAGRo
AAAAAGRoa7N6ZiUACIEWaMdfsQAXaHwKWwBjSAEAZGgAAAAAZGgAAAAAZGhrs3pmEwEIgQRI
AQAFaGqzemYWaHwKWwAlAAiBFmjHX7EAF2h8ClsAY0gBAGRoAAAAAGRoAAAAAGRoarN6ZhMB
CIEESAEABWiLsnpmFmjudXMAJQAIgRZox1+xABdo7nVzAGNIAQBkaAAAAABkaAAAAABkaIuy
emYTAQiBBEgBAAVoa7N6ZhZofApbAAYWaMdfsQAejicAAOInAADpJwAA7ycAAPAnAAD7JwAA
BCgAAA4oAAAwKAAANigAADkoAAA6KAAAUSgAAFcoAABgKAAAbigAAHUoAAB7KAAAhigAAIco
AACpKAAAqigAAKsoAACtKAAAuSgAALwoAAD87+Tc/Mm//LfkrPy35PyhmY7c/Ip3ZFFkAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAIgRZoTnWdABdoFhhyAGNIAQBkaAAA
AABkaAAAAABkaKqyemYlAAiBFmjHX7EAF2gWGHIAY0gBAGRoAAAAAGRoAAAAAGRoqrJ6ZiUA
CIEWaBRHHQAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGiqsnpmBhZoTnWdAAAVFWjWTxwAFmhz
YxgAQioGcGj/ZgAADxZoDSpYAEIqBnBo/2YAABUVaNZPHAAWaNZPHABCKgZwaP9mAAAVFWhz
YxgAFmhzYxgAQioHcGj/zAAADxZoDSpYAEIqB3Bo/5kAABMBCIEESAEABWhks3pmFmh8ClsA
JQAIgRZoc2MYABdofApbAGNIAQBkaAAAAABkaAAAAABkaGSzemYPFmhzYxgAQioHcGj/mQAA
FRVoc2MYABZoc2MYAEIqB3Bo/5kAABgVaHNjGAAWaHNjGAA2CIFCKgdwaP+ZAAAABhZoc2MY
ABm8KAAAwCgAAMIoAADwKAAAECkAACYpAAAqKQAALikAAC8pAAA6KQAARykAAEgpAABTKQAA
VikAAFopAABeKQAAZSkAAIMpAACHKQAAjCkAAJYpAACaKQAAnikAAK4pAADs2ca8uKWbuKW4
kX647HRwbGhsaFVLbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAQiBBEgBAAVo
n7J6ZhZoFhhyACUACIEWaBRHHQAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGifsnpmBhZoDSpY
AAAGFmgURx0AAAYWaMdfsQAAEwEIgQRIAQAFaIKyemYWaO51cwAlAAiBFmhOdZ0AF2h8ClsA
Y0gBAGRoAAAAAGRoAAAAAGRoZ7N6ZhMBCIEESAEABWhns3pmFmh8ClsAEwEIgQRIAQAFaGaz
emYWaHwKWwAlAAiBFmhOdZ0AF2h8ClsAY0gBAGRoAAAAAGRoAAAAAGRoZrN6ZgYWaE51nQAA
EwEIgQRIAQAFaKuyemYWaBYYcgAlAAiBFmhOdZ0AF2gWGHIAY0gBAGRoAAAAAGRoAAAAAGRo
qrJ6ZiUACIEWaMdfsQAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGiqsnpmJQAIgRZox1+xABdo
7nVzAGNIAQBkaAAAAABkaAAAAABkaIKyemYAF64pAACyKQAAtikAAMQpAADXKQAA4ykAAOop
AADrKQAA7CkAACgqAAAuKgAANSoAAD0qAAA+KgAARioAAEcqAACJKgAAiioAAI4qAACeKgAA
rSoAAOIqAADoKgAA8ioAABgrAAAcKwAAHysAAD4rAABUKwAA+CsAAP4rAAASLAAAIiwAAFIs
AAB7LAAAmSwAALQsAADcLAAA6iwAAAYtAAAKLQAAEy0AABgtAADs4t7ax73eubXavaLetZ6a
tZ6anpramp6anpqemp6anod9mnmatbl1ubUAAAAAAAAAAAAAAAAAAAAAAAAAAAYWaBIb7wAA
BhZo1k8cAAATAQiBBEgBAAVourJ6ZhZo62FbACUACIEWaHZ7IgAXaOthWwBjSAEAZGgAAAAA
ZGgAAAAAZGi6snpmBhZodnsiAAAGFmhzYxgAACUACIEWaBRHHQAXaOthWwBjSAEAZGgAAAAA
ZGgAAAAAZGirsnpmBhZoTnWdAAAGFmjHX7EAABMBCIEESAEABWirsnpmFmjrYVsAJQAIgRZo
DSpYABdo62FbAGNIAQBkaAAAAABkaAAAAABkaKuyemYGFmgNKlgAAAYWaBRHHQAAEwEIgQRI
AQAFaIKyemYWaO51cwAlAAiBFmgURx0AF2judXMAY0gBAGRoAAAAAGRoAAAAAGRogrJ6ZgAq
HCsAAPkrAADcLAAAOC4AAGkuAACNLgAAvi4AAHovAAAtMAAALjAAAJ4xAACfMQAAfDMAAFE0
AABSNAAAZDQAAJ01AAB/NgAAgTYAAKA2AADONgAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA
AADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA
7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0A
AAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAA
AAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA3QAAAAAA
AAAAAAAAANgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAQAAGdk9Wl5AAgDAAomAAtGAABnZKo/BQAIAgAKJgALRgAAZ2SqPwUAAAQAAGdklhHjAAAM
AAAPhOAQEYSI8F6E4BBghIjwZ2R2eyIAABQYLQAAHC0AACAtAAArLQAAMS0AADctAAA8LQAA
Ri0AAEctAABSLQAAsC0AADcuAAA4LgAAlC4AALcuAAACLwAAIC8AACIvAAAjLwAAWy8AAHkv
AADZLwAA2i8AAC0wAAAyMAAANzAAAD0wAABIMAAATDAAAFAwAACIMAAAjDAAAJAwAACTMAAA
7OLs3trQ3uLszMjayMTIwMjAyMDIwMi8qZ+8jIK8b2W8AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAEwEIgQRIAQAFaKCyemYWaBYYcgAlAAiBFmj+WU8AF2gWGHIAY0gBAGRo
AAAAAGRoAAAAAGRooLJ6ZhMBCIEESAEABWiDsnpmFmjudXMAJQAIgRZo/llPABdo7nVzAGNI
AQBkaAAAAABkaAAAAABkaIOyemYTAQiBBEgBAAVo0rJ6ZhZoghA9ACUACIEWaP5ZTwAXaIIQ
PQBjSAEAZGgAAAAAZGgAAAAAZGjSsnpmBhZo/llPAAAGFmjWTxwAAAYWaBRHHQAABhZoJGwO
AAAGFmjHX7EAABMBCIEESAEABWjAsnpmFmgKENoABhZoa37lAAAGFmhOdZ0AABMBCIEESAEA
BWhns3pmFmh8ClsAJQAIgRZoTnWdABdofApbAGNIAQBkaAAAAABkaAAAAABkaGezemYAIZMw
AACXMAAAmzAAAKwwAACuMAAAsDAAALUwAAC9MAAAwTAAAMcwAADkMAAA6DAAAOwwAADtMAAA
8TAAAPUwAAD7MAAAHjEAACIxAAAmMQAAJzEAACsxAAAvMQAAMTEAADYxAAA4MQAAPjEAAEAx
AABFMQAARzEAAE8xAABUMQAAXTEAAHUxAACBMQAAhTEAAIkxAACdMQAAnjEAAOzi3tPe08Te
096xp97T3tPesafelIre097T3tPe097T3oZzaYbeAAAAAAAAAAAAAAAAAAAAABMBCIEESAEA
BWiFsnpmFmjudXMAJQAIgRZoFEcdABdo7nVzAGNIAQBkaAAAAABkaAAAAABkaIWyemYGFmgU
Rx0AABMBCIEESAEABWiDsnpmFmjudXMAJQAIgRZo/llPABdo7nVzAGNIAQBkaAAAAABkaAAA
AABkaIOyemYTAQiBBEgBAAVooLJ6ZhZoFhhyACUACIEWaP5ZTwAXaBYYcgBjSAEAZGgAAAAA
ZGgAAAAAZGigsnpmHAEIgQRIAQAFaNyyemYWaIIQPQBCKgZwaP9mAAAAFRVo/llPABZo/llP
AEIqBnBo/2YAAAYWaP5ZTwAAEwEIgQRIAQAFaJGyemYWaO51cwAlAAiBFmj+WU8AF2judXMA
Y0gBAGRoAAAAAGRoAAAAAGRokbJ6ZgAmnjEAAJ8xAADSMgAA6jIAAAszAAB5MwAAezMAAHwz
AADSMwAA1jMAAFA0AABRNAAAUjQAAGI0AABkNAAAzDQAAJ01AADJNQAAzDUAABo2AACANgAA
gTYAAIY2AACHNgAAzjYAAN42AADsNgAA8zYAAAU3AAAGNwAAFDcAACQ3AAAlNwAAUDcAAPfs
5Nzk1Mm+tr6uqJ+blJuQm5SQm4ybiIJ8gnZwdmqCagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAKFmg/eSAAMEoTAAAKFmj1aXkAMEoTAAAKFmghcJ4AMEoT
AAAKFmjWTxwAMEoTAAAKFmiWEeMAMEoTAAAGFmj1aXkAAAYWaKo/BQAABhZoP3kgAAAMFWin
f9IAFmghcJ4AAAYWaCFwngAAEBVoqj8FABZoIXCeADBKKAAAChZo/llPADBKKAAADxZoIXCe
AEIqB3Bo/5kAAA8WaKo/BQBCKgdwaP+ZAAAVFWghcJ4AFmghcJ4AQioHcGj/mQAAFRVoIXCe
ABZoJGwOAEIqB3Bo/5kAAA8WaNZPHABCKgdwaP+ZAAAPFmg5PcoAQioHcGj/mQAADxZoJGwO
AEIqB3Bo/5kAABUVaCFwngAWaBJYlABCKgdwaP+ZAAAPFmj+WU8AQioHcGj/mQAAACHONgAA
3jYAAPM2AAAGNwAAtQAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAAAhAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAASQAACiYAC0YZAEXGgAEAAQBlsnpmAQAAAAAAAAAAAAQCAAQCAAQCAAADAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2RuZvkAAEkAAAom
AAtGGQBFxoABAAEAZbJ6ZgEAAAAAAAAAAAAEAgAEAgAEAgAAAgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkbmb5AABJAAAKJgALRhkARcaAAQABAGWy
emYBAAAAAAAAAAAABAIABAIABAIAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABnZG5m+QAAAwY3AAAUNwAAIjcAAFk3AAC1AAAAAAAAAAAAAAAAawAA
AAAAAAAAAAAAACEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJAAAKJgALRhkARcaAAQABAGWy
emYBAAAAAAAAAAAABAIABAIABAIAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABnZD95IAAASQAACiYAC0YZAEXGgAEAAQBlsnpmAQAAAAAAAAAAAAQC
AAQCAAQCAAAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Z2RuZvkAAEkAAAomAAtGGQBFxoABAAEAZbJ6ZgEAAAAAAAAAAAAEAgAEAgAEAgAABAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkbmb5AAADUDcAAFU3
AABYNwAAWTcAAGs3AABsNwAAejcAAI43AACTNwAASTgAAEo4AABwOAAAdTgAAJE4AADTOAAA
ATkAABA5AAAgOQAAJDkAACg5AAApOQAAODkAAEU5AABJOQAATTkAAE45AABTOQAAXzkAAGc5
AACBOQAA6t7V0c3RzcTRwNG80biyrLKXi7KshXBkhV6sXrIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAKFmgNKlgAMEoTAAAXAQiBBEgBAAVooLJ6ZhZoFhhyADBK
EwApAAiBFmj1dBcAF2gWGHIAMEoTAGNIAQBkaAAAAABkaAAAAABkaKCyemYKFmj1dBcAMEoT
AAAXAQiBBEgBAAVolLJ6ZhZo7nVzADBKEwApAAiBFmg/eSAAF2judXMAMEoTAGNIAQBkaAAA
AABkaAAAAABkaJSyemYKFmgkbA4AMEoTAAAKFmg/eSAAMEoTAAAGFmj1dBcAAAYWaKo/BQAA
BhZoOT3KAAAQFWhuZvkAFmhuZvkAMEoTAAAGFmhuZvkAAAYWaD95IAAAEBVoUG4pABZo9Wl5
ADBKEwAAFwEIgQRIAQAFaO+yemYWaH4+ggAwShMAKQAIgRZoP3kgABdofj6CADBKEwBjSAEA
ZGgAAAAAZGgAAAAAZGjvsnpmAB1ZNwAAcDgAAJE4AADSOAAA0zgAAAE5AAApOQAA+gAAAAAA
AAAAAAAAAPIAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAKgAAAAAAAAA
AAAAAABeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJAAAKJgAL
RiIARcaAAQABAGWyemYBAAAAAAAAAAAABAIABAIABAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZD95IAAASQAACiYAC0YiAEXGgAEAAQBlsnpm
AQAAAAAAAAAAAAQCAAQCAAQCAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAZ2Q/eSAACAMACiYAC0YAAGdkqj8FAAAEAABnZG5m+QAABik5AABOOQAA
ijkAAKg5AAC1AAAAAAAAAAAAAAAAawAAAAAAAAAAAAAAACEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABJAAAKJgALRiIARcaAAQABAGWyemYBAAAAAAAAAAAABAIABAIABAIAAAUAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZPV0FwAASQAACiYAC0Yi
AEXGgAEAAQBlsnpmAQAAAAAAAAAAAAQCAAQCAAQCAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2Q/eSAAAEkAAAomAAtGIgBFxoABAAEAZbJ6ZgEA
AAAAAAAAAAAEAgAEAgAEAgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAGdkP3kgAAADgTkAAIU5AACJOQAAijkAAI45AACYOQAAoDkAANA5AADwOQAA
9DkAAPg5AAD5OQAAQDoAAEY6AABNOgAAUDoAAGQ6AACMOgAAjToAAL86AAA7OwAAPDsAAD07
AABDOwAAXDsAAF47AACWOwAAlzsAAKM7AACvOwAA4zsAAOQ7AADsOwAA7jsAAAY8AADq3tjS
zNjMxrGlzMaQhMbM0n7SfsxrZ2BnYFxgZ2BcYGdgAAAAAAAAAAAAAAYWaKI12AAADBVop3/S
ABZosUpmAAAGFmiqPwUAACQVaDk9ygAWaPV0FwA1CIFCKgZDShIAT0oDAFFKAwBwaP9mAAAA
ChZoOT3KADBKEwAAFwEIgQRIAQAFaLSyemYWaOthWwAwShMAKQAIgRZoDSpYABdo62FbADBK
EwBjSAEAZGgAAAAAZGgAAAAAZGi0snpmFwEIgQRIAQAFaJayemYWaO51cwAwShMAKQAIgRZo
DSpYABdo7nVzADBKEwBjSAEAZGgAAAAAZGgAAAAAZGiWsnpmChZoDSpYADBKEwAAChZo9XQX
ADBKEwAAChZoJGwOADBKEwAAChZoP3kgADBKEwAAFwEIgQRIAQAFaJWyemYWaO51cwAwShMA
KQAIgRZoP3kgABdo7nVzADBKEwBjSAEAZGgAAAAAZGgAAAAAZGiVsnpmACKoOQAAyzkAAPk5
AAAlOgAAUDoAAI06AAC/OgAA6joAABE7AAA7OwAAPTsAAFQ7AACXOwAA5DsAAAc8AAAoPAAA
OjwAAE88AAC1AAAAAAAAAAAAAAAArAAAAAAAAAAAAAAAAKwAAAAAAAAAAAAAAACsAAAAAAAA
AAAAAAAAowAAAAAAAAAAAAAAAKwAAAAAAAAAAAAAAACsAAAAAAAAAAAAAAAArAAAAAAAAAAA
AAAAAKwAAAAAAAAAAAAAAACjAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAJYAAAAAAAAAAAAA
AACWAAAAAAAAAAAAAAAAlgAAAAAAAAAAAAAAAJYAAAAAAAAAAAAAAACWAAAAAAAAAAAAAAAA
lgAAAAAAAAAAAAAAAAAAAAAAAAAABBUAZ2RQbikACAMACiYAC0YAAGdkqj8FAAAIAAAPhGgB
XoRoAWdkOT3KAAAIAAAPhGgBXoRoAWdk9XQXAABJAAAKJgALRiIARcaAAQABAGWyemYBAAAA
AAAAAAAABAIABAIABAIAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABnZPV0FwAAEQY8AAAHPAAADzwAABE8AAAVPAAAFjwAADE8AAAzPAAAOjwAAEY8
AABIPAAATzwAAFc8AABZPAAAYDwAAGE8AABlPAAAbzwAAHM8AAB1PAAAdjwAAHo8AAB7PAAA
jDwAAJA8AACaPAAAnjwAAKU8AACmPAAAqzwAALY8AAC3PAAAuzwAALw8AAC9PAAAwTwAAMs8
AADPPAAA0DwAANE8AADSPAAA1jwAANo8AADbPAAA3DwAAN48AADjPAAA5zwAAPE8AAD1PAAA
+DwAAPz49Pj0+PT48PTw+PT46dO9s+n06fTp072z6a/p/PT89PycibP8r/zTf+n89PycibP8
EwEIgQRIAQAFaJeyemYWaO51cwAlAAiBFmggcnkAF2gWGHIAY0gBAGRoAAAAAGRoAAAAAGRo
orJ6ZiUACIEWaCByeQAXaO51cwBjSAEAZGgAAAAAZGgAAAAAZGiXsnpmBhZoojXYAAATAQiB
BEgBAAVoorJ6ZhZoFhhyACsACIEVaKd/0gAWaLFKZgAXaBYYcgBjSAEAZGgAAAAAZGgAAAAA
ZGiisnpmKwAIgRVop3/SABZosUpmABdo7nVzAGNIAQBkaAAAAABkaAAAAABkaJeyemYMFWin
f9IAFmixSmYAAAYWaG5m+QAABhZoqj8FAAAGFmi3QwMAAAYWaCByeQAyTzwAAGA8AACmPAAA
0TwAACA9AABiPQAAgT0AAJM9AADDPQAA5z0AABg+AABcPgAAkj4AAJM+AAC0PgAAtT4AAMg+
AAAaQAAAL0AAAHZAAAB9QAAAQkIAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA
AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA
AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA
AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA
AO0AAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADX
AAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdk1kuSAAkWABYkAUlmAQAAAGdk
1kuSAAgDAAomAAtGAABnZPxrLgAABAAAZ2R1eXgACAIACiYAC0YAAGdk/GsuAAAEAABnZLdD
AwAABBUAZ2RQbikAABX4PAAA/DwAAAA9AAABPQAACz0AAAw9AAAQPQAAGj0AAB49AAAfPQAA
ID0AACE9AAAiPQAAJj0AACo9AAAsPQAALj0AAEI9AABJPQAASz0AAE89AABTPQAAVD0AAFg9
AABcPQAAYD0AAGE9AABiPQAAZz0AAG49AABwPQAAcT0AAHM9AAB0PQAAdz0AAHs9AAB/PQAA
gT0AAK09AACxPQAAtT0AAOnf2NTY6b602LDYrJnf2JXY1NiZ39ismd+ssJGNkZWRlZF635GN
Z98AACUACIEWaDk9ygAXaO51cwBjSAEAZGgAAAAAZGgAAAAAZGiXsnpmJQAIgRZo9XQXABdo
7nVzAGNIAQBkaAAAAABkaAAAAABkaJeyemYGFmg5PcoAAAYWaPV0FwAABhZoqj8FAAAlAAiB
FmggcnkAF2judXMAY0gBAGRoAAAAAGRoAAAAAGRol7J6ZgYWaCByeQAABhZoojXYAAATAQiB
BEgBAAVoo7J6ZhZoFhhyACsACIEVaKd/0gAWaLFKZgAXaBYYcgBjSAEAZGgAAAAAZGgAAAAA
ZGijsnpmBhZot0MDAAAMFWinf9IAFmixSmYAABMBCIEESAEABWiXsnpmFmjudXMAKwAIgRVo
p3/SABZosUpmABdo7nVzAGNIAQBkaAAAAABkaAAAAABkaJeyemYAKLU9AADdPQAA4T0AAOU9
AAABPgAABT4AAAk+AAAYPgAAKj4AADE+AAAyPgAAWz4AAGw+AACRPgAAkz4AALM+AAC0PgAA
tT4AAMc+AADIPgAA2j4AANs+AADePgAAAz8AAAc/AAALPwAAHT8AAB8/AAAjPwAAJz8AAFA/
AABuPwAAcj8AAHY/AACVPwAAnj8AAKI/AAD86d/86d/82/zb/Nv829Tb0MnC/ND80K/f0KuY
36vQhXvQd2QAAAAAAAAAAAAAAAAAAAAAJQAIgRZot1+4ABdo7nVzAGNIAQBkaAAAAABkaAAA
AABkaJmyemYGFmi3X7gAABMBCIEESAEABWigsnpmFmgWGHIAJQAIgRZodXl4ABdoFhhyAGNI
AQBkaAAAAABkaAAAAABkaKCyemYlAAiBFmjWTxwAF2judXMAY0gBAGRoAAAAAGRoAAAAAGRo
mLJ6ZgYWaNZPHAAAJQAIgRZodXl4ABdo7nVzAGNIAQBkaAAAAABkaAAAAABkaJiyemYMFWj8
ay4AFmiqPwUAAAwVaPxrLgAWaHV5eAAABhZodXl4AAAMFWiqPwUAFmi3QwMAAAYWaKo/BQAA
EwEIgQRIAQAFaJiyemYWaO51cwAlAAiBFmg5PcoAF2judXMAY0gBAGRoAAAAAGRoAAAAAGRo
mLJ6ZgYWaDk9ygAkoj8AAKY/AAAYQAAAGUAAABpAAAAcQAAAH0AAAC1AAAAvQAAAcUAAAHNA
AADRQAAA+EAAAP5AAAD/QAAADEEAABFBAABuQQAAckEAAHpBAAAaQgAAI0IAADVCAABAQgAA
QUIAAEJCAABDQgAAV0IAAFtCAABfQgAAqUMAAK9DAAC2QwAAz0MAAOtDAACKRAAA9fHt6eHZ
0c3pzenJvsm6r7qckrqvuq+67emOe/WOaF6O8Y4AAAAAAAAAAAATAQiBBEgBAAVotLJ6ZhZo
62FbACUACIEWaN9ZlgAXaOthWwBjSAEAZGgAAAAAZGgAAAAAZGi0snpmJQAIgRZo31mWABdo
7nVzAGNIAQBkaAAAAABkaAAAAABkaJmyemYGFmjfWZYAABMBCIEESAEABWjzsnpmFmh+PoIA
JQAIgRZoWwMlABdofj6CAGNIAQBkaAAAAABkaAAAAABkaPOyemYVFWhbAyUAFmhbAyUAQioG
cGj/ZgAABhZoWwMlAAAVFWg5PcoAFmg5PcoAQioGcGj/ZgAABhZoOT3KAAAGFmiqPwUAAA8V
aPxrLgAWaKo/BQBcCIEPFWj8ay4AFmj8ay4AXAiBDxVo/GsuABZodXl4AFwIgQYWaHV5eAAA
BhZo/GsuAAAGFmi3X7gAABMBCIEESAEABWiZsnpmFmjudXMAACNCQgAAQ0IAAEtCAADYRAAA
2UQAAN9EAAA9RQAAuwAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAZQAA
AAAAAAAAAAAAALIAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAa2R+JAIAFiQBFyQBSWYBAAAACNYwAAJt/9AC
RCOABmMDAAAAAAAAAAAAAAAAAAAAAAAGdCAAAAAAAAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2
AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP9h9gNt/wkA
ABYkAUlmAQAAAGdk1kuSAAkWABYkAUlmAQAAAGdk1kuSAEQAAGtkGCQCABYkARckAUlmAQAA
AAjWMAACbf/QAkQjgAZjAwAAAAAAAAAAAAAAAAAAAAAABnQgAAAAAAAAAAAAAAAAAAAAABT2
A9cjF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8A
AAD/YfYDbf8ABopEAACkRAAA2UQAAO1EAAANRQAAPkUAAGtFAAB1RQAAtUYAAMtGAAAMRwAA
MUcAAE5HAADERwAA6UcAAOpHAABcSQAAeEkAAHlJAACfSQAADEoAABlKAACzSgAAtEoAANdK
AADYSgAA2UoAANxKAADlSgAA5koAAD1LAABBSwAAQksAAENLAABHSwAASksAAI9LAACQSwAA
uEsAAL1LAADGSwAAyEsAAM1LAAAXTAAAG0wAAI9MAACWTAAAv0wAAMBMAAAITQAACU0AACJN
AAAjTQAA/Pj08PTs9Ozh2eHZ4dnh7PTw9Oz07NHsxtHC7NHsueyy7Lnssuy57K6jrqOumK6R
7NHshgAAAAAVAgiBA2rpKQIABggBFmh8ClsAVQgBDBVobmb5ABZot1+4AAAVFWj+WU8AFmi3
X7gAQioGcGj/ZgAAFRVot1+4ABZot1+4AEIqBnBo/2YAAAYWaLdfuAAADBVobmb5ABZodXl4
AAAQFWhXIdAAFmh1eXgAMEoTAAAGFmgNKlgAABUCCIEDakYpAgAGCAEWaHwKWwBVCAEPA2oA
AAAAFmh1eXgAVQgBDxZoDSpYAEIqBnBo/2YAABUVaA0qWAAWaA0qWABCKgZwaP9mAAAGFmh1
eXgAAAYWaDk9ygAABhZo/GsuAAAGFmjfWZYAAAYWaBIb7wA0PUUAAD5FAABDRQAAlEUAAJVF
AACcRQAA9UUAALsAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAGUAAAAA
AAAAAAAAAACyAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAGtkSiUCABYkARckAUlmAQAAAAjWMAACbf/QAkQj
gAZjAwAAAAAAAAAAAAAAAAAAAAAABnQgAAAAAAAAAAAAAAAAAAAAABT2A9cjF/YDAAAY9gMA
ABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/YfYDbf8JAAAW
JAFJZgEAAABnZNZLkgAJFgAWJAFJZgEAAABnZNZLkgBEAABrZOQkAgAWJAEXJAFJZgEAAAAI
1jAAAm3/0AJEI4AGYwMAAAAAAAAAAAAAAAAAAAAAAAZ0IAAAAAAAAAAAAAAAAAAAAAAU9gPX
Ixf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA
/2H2A23/AAb1RQAA9kUAAPtFAABSRgAAU0YAAFlGAAC1RgAACUcAAOpHAAC7AAAAAAAAAAAA
AAAAsgAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAABlAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAA
AKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAa2QW
JgIAFiQBFyQBSWYBAAAACNYwAAJt/9ACRCOABmMDAAAAAAAAAAAAAAAAAAAAAAAGdCAAAAAA
AAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAA
AP8AAAD/HdYIAAAA/wAAAP9h9gNt/wkAABYkAUlmAQAAAGdk1kuSAAkWABYkAUlmAQAAAGdk
1kuSAEQAAGtksCUCABYkARckAUlmAQAAAAjWMAACbf/QAkQjgAZjAwAAAAAAAAAAAAAAAAAA
AAAABnQgAAAAAAAAAAAAAAAAAAAAABT2A9cjF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA
/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/YfYDbf8ACOpHAADrRwAA8UcAAI9IAACQSAAA
lUgAAFtJAAC7AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAABlAAAAAAAA
AAAAAAAAsgAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABEAABrZOImAgAWJAEXJAFJZgEAAAAI1jAAAm3/0AJEI4AG
YwMAAAAAAAAAAAAAAAAAAAAAAAZ0IAAAAAAAAAAAAAAAAAAAAAAU9gPXIxf2AwAAGPYDAAAa
1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/2H2A23/CQAAFiQB
SWYBAAAAZ2TWS5IACRYAFiQBSWYBAAAAZ2TWS5IARAAAa2R8JgIAFiQBFyQBSWYBAAAACNYw
AAJt/9ACRCOABmMDAAAAAAAAAAAAAAAAAAAAAAAGdCAAAAAAAAAAAAAAAAAAAAAAFPYD1yMX
9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP9h
9gNt/wAGW0kAAFxJAABhSQAAnkkAAJ9JAAClSQAA1kkAALsAAAAAAAAAAAAAAACyAAAAAAAA
AAAAAAAAqQAAAAAAAAAAAAAAAGUAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAqQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAGtkricC
ABYkARckAUlmAQAAAAjWMAACbf/QAkQjgAZjAwAAAAAAAAAAAAAAAAAAAAAABnQgAAAAAAAA
AAAAAAAAAAAAABT2A9cjF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/
AAAA/x3WCAAAAP8AAAD/YfYDbf8JAAAWJAFJZgEAAABnZNZLkgAJFgAWJAFJZgEAAABnZNZL
kgBEAABrZEgnAgAWJAEXJAFJZgEAAAAI1jAAAm3/0AJEI4AGYwMAAAAAAAAAAAAAAAAAAAAA
AAZ0IAAAAAAAAAAAAAAAAAAAAAAU9gPXIxf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8A
AAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/2H2A23/AAbWSQAA10kAANxJAABkSgAAZUoAAGpK
AACGSgAAuwAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAZQAAAAAAAAAA
AAAAALIAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAARAAAa2R6KAIAFiQBFyQBSWYBAAAACNYwAAJt/9ACRCOABmMD
AAAAAAAAAAAAAAAAAAAAAAAGdCAAAAAAAAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2AwAAGtYI
AAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP9h9gNt/wkAABYkAUlm
AQAAAGdk1kuSAAkWABYkAUlmAQAAAGdk1kuSAEQAAGtkFCgCABYkARckAUlmAQAAAAjWMAAC
bf/QAkQjgAZjAwAAAAAAAAAAAAAAAAAAAAAABnQgAAAAAAAAAAAAAAAAAAAAABT2A9cjF/YD
AAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/YfYD
bf8ABoZKAACHSgAACksAAENLAAC7AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAAGwAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABJGAAKJgALRggARcaAAQABAGWyemYAAAAAAAAAAAAXFxcXFxcXFxcAAAMAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAt/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZHV5eAAABAAAZ2R1eXgA
RAAAa2TgKAIAFiQBFyQBSWYBAAAACNYwAAJt/9ACRCOABmMDAAAAAAAAAAAAAAAAAAAAAAAG
dCAAAAAAAAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA
/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP9h9gNt/wADQ0sAAJBLAADGSwAAFUwAALUAAAAAAAAA
AAAAAABrAAAAAAAAAAAAAAAAIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEkYAAomAAtGCABF
xoABAAEAZbJ6ZgAAAAAAAAAAABcXFxcXFxcXFwAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAQC38AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkdXl4AABJGAAKJgALRggARcaAAQABAGWyemYAAAAA
AAAAAAAXFxcXFxcXFxcAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA
t/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABnZHV5eAAASRgACiYAC0YIAEXGgAEAAQBlsnpmAAAAAAAAAAAAFxcXFxcXFxcX
AAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABALfwAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2R1eXgA
AAMVTAAAf0wAAMBMAAAzTQAANE0AAFBNAADITgAAyU4AAM1OAAC1AAAAAAAAAAAAAAAAawAA
AAAAAAAAAAAAAGYAAAAAAAAAAAAAAABmAAAAAAAAAAAAAAAAXgAAAAAAAAAAAAAAAFkAAAAA
AAAAAAAAAABZAAAAAAAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
CRYAFiQBSWYBAAAAZ2TWS5IAAAQAAGdkFG/oAAgDAAomAAtGAABnZBRv6AAABAAAZ2R/WAEA
AEkYAAomAAtGCABFxoABAAEAZbJ6ZgAAAAAAAAAAABcXFxcXFxcXFwAACAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQC38AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkt1+4AABJGAAKJgALRggARcaA
AQABAGWyemYAAAAAAAAAAAAXFxcXFxcXFxcAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAEAt/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABnZLdfuAAACCNNAAAkTQAAKU0AACpNAAAyTQAAM00AADRN
AAA2TQAAQk0AAENNAABOTQAAVk0AAFpNAABeTQAAk00AAMdOAADITgAAyU4AAMxPAADOTwAA
z08AANNPAADXTwAAOFAAAJFQAACXUAAAmVAAAPdQAAAbUQAAHVEAAPfz9/Pv6ODbz7q2o5m2
lbaRtoa2c2m2ZbZatlZLABUVaDhTKAAWaBRv6ABCKgZwaP9mAAAGFmg4UygAABUVaFsDJQAW
aBRv6ABCKgZwaP9mAAAGFmhbAyUAABMBCIEESAEABWihsnpmFmgWGHIAJQAIgRZoFG/oABdo
FhhyAGNIAQBkaAAAAABkaAAAAABkaKGyemYVFWhbdbcAFmgUb+gAQioGcGj/ZgAABhZoW3W3
AAAGFmh/WAEAABMBCIEESAEABWiZsnpmFmjudXMAJQAIgRZoFG/oABdo7nVzAGNIAQBkaAAA
AABkaAAAAABkaJmyemYGFmgUb+gAACgACIEWaBRv6AAXaHwKWwBcCIFjSAEAZGgAAAAAZGgA
AAAAZGhos3pmABYBCIEESAEABWhos3pmFmh8ClsAXAiBAAkWaBRv6ABcCIEPFWj8ay4AFmgU
b+gAXAiBDBVof1gBABZof1gBAAAGFmjhXsUAAAYWaHV5eAAADwNqAAAAABZodXl4AFUIAQAd
zU4AAARQAAAFUAAAC1AAACtSAAD6UgAA+1IAAAJTAAA0VAAA9gAAAAAAAAAAAAAAALIAAAAA
AAAAAAAAAACpAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAABlAAAAAAAA
AAAAAAAAqQAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAGtkJysCABYkARck
AUlmAQAAAAjWMAACbf9fAkQjgAbyAgAAAAAAAAAAAAAAAAAAAAAABuUgAAAAAAAAAAAAAAAA
AAAAABT2A9cjF/YDAAAY9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3W
CAAAAP8AAAD/YfYDbf8JFgAWJAFJZgEAAABnZNZLkgBEAABrZMEqAgAWJAEXJAFJZgEAAAAI
1jAAAm3/XwJEI4AG8gIAAAAAAAAAAAAAAAAAAAAAAAblIAAAAAAAAAAAAAAAAAAAAAAU9gPX
Ixf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA
/2H2A23/CQAAFiQBSWYBAAAAZ2TWS5IAAAgdUQAAIlEAACVRAAA0UQAAN1EAAJNRAACUUQAA
sVEAALRRAAC2UQAABlIAAApSAAALUgAAEFIAAClSAAArUgAAeFIAAHpSAACoUgAAsFIAALVS
AAC7UgAAwFIAAMZSAAD5UgAA+lIAAPtSAAACVAAAFVQAADVUAAD88fzx/O3i2tLtx7KXx+2T
iJOIk4htXpNX/FNPUwAAAAAAAAAAAAYWaGhh0gAABhZoOFMoAAAMFWjfWZYAFmhbAyUAABwB
CIEESAEABWgDs3pmFmgTZGcAQioGcGj/ZgAAADQACIEVaFsDJQAWaFsDJQAXaBNkZwBCKgZj
SAEAZGgAAAAAZGgAAAAAZGgDs3pmcGj/ZgAAABUVaFsDJQAWaFsDJQBCKgZwaP9mAAAGFmhb
AyUAADQACIEVaN9ZlgAWaN9ZlgAXaBNkZwBCKgZjSAEAZGgAAAAAZGgAAAAAZGj7snpmcGj/
ZgAAACgBCIEESAEABWj7snpmFWjfWZYAFmgTZGcAF2gTZGcAQioGcGj/ZgAAABUVaN9ZlgAW
aN9ZlgBCKgZwaP9mAAAPFmjfWZYAQioGcGj/ZgAADxZoOFMoAEIqBnBo/2YAABUVaDk9ygAW
aBRv6ABCKgZwaP9mAAAGFmjfWZYAABUVaDhTKAAWaBRv6ABCKgZwaP9mAAAGFmgUb+gAHTRU
AAA1VAAANlQAAIdUAACIVAAApVQAAPdWAAD4VgAAolcAAEhYAABJWAAAdFgAAHVYAAB8WAAA
LlkAAChaAABSXgAALl8AALsAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAArgAAAAAAAAAAAAAA
ALMAAAAAAAAAAAAAAACzAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACp
AAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAA
AAAAAAAAAAAAAKAAAAAAAAAAAAAAAACXAAAAAAAAAAAAAAAAlwAAAAAAAAAAAAAAAJcAAAAA
AAAAAAAAAACXAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2TWS5IACRYAFiQB
SWYBAAAAZ2TWS5IAAAQAAGdkFG/oAAAEAABnZLdfuAAIAwAKJgALRgAAZ2QUb+gARAAAa2SN
KwIAFiQBFyQBSWYBAAAACNYwAAJt/18CRCOABvICAAAAAAAAAAAAAAAAAAAAAAAG5SAAAAAA
AAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAA
AP8AAAD/HdYIAAAA/wAAAP9h9gNt/wARNVQAADZUAABbVAAAYFQAAGVUAABrVAAAbFQAAIZU
AACHVAAAiFQAAIpUAACXVAAAmFQAAKNUAACuVAAAr1QAALBUAAC7VAAAwlQAAOBUAAALVQAA
EFUAABFVAAAVVQAAG1UAACBVAAAoVQAAZ1UAAGpVAABWVgAAkVYAAJtWAACgVgAAo1YAAPr2
6/bj6/bc+tTPw66qoKqNqomFeoV6b6pvqoWqa2BVYAAVFWhoYdIAFmhoYdIAQioGcGj/ZgAA
FRVoaGHSABZoeA79AEIqBnBo/2YAAAYWaHgO/QAAFRVoaGHSABZoFG/oAEIqBnBo/2YAABUV
aGhh0gAWaDhTKABCKgZwaP9mAAAGFmg4UygAAAYWaGhh0gAAJQAIgRZoFG/oABdofApbAGNI
AQBkaAAAAABkaAAAAABkaGizemYTAQiBBEgBAAVoaLN6ZhZofApbAAYWaBRv6AAAKAAIgRZo
FG/oABdofApbAFwIgWNIAQBkaAAAAABkaAAAAABkaGizemYAFgEIgQRIAQAFaGizemYWaHwK
WwBcCIEACRZoFG/oAFwIgQ8VaPxrLgAWaBRv6ABcCIEMFWi3X7gAFmi3X7gAAA8WaLdfuABC
KgZwaP9mAAAVFWi3X7gAFmi3X7gAQioGcGj/ZgAABhZot1+4AAAJFmi3X7gAXAiBACGjVgAA
y1YAAPZWAAAYVwAAGVcAABpXAAAbVwAAJlcAAKFXAACiVwAAs1cAALRXAAAUWAAAGFgAAGVY
AAByWAAAdFgAAHVYAAC8WAAAwlgAAMlYAADkWAAA6lgAAO9YAADzWAAADVkAABJZAAAuWQAA
NFkAAIZZAACMWQAAk1kAANFZAADWWQAA11kAAN1ZAADkWQAA7lkAAPRZAAD7WQAAKFoAACxa
AAA4WgAAQVoAAFZaAAD8+Pz06vTX9PzTydO20/jTr6uYjquDq4Org6uDq5iOq4OrmI6rmI6r
g6vTfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYWaGhh0gAAFRVoaGHSABZoplpb
AEIqBnBo/2YAABMBCIEESAEABWi1snpmFmjrYVsAJQAIgRZoplpbABdo62FbAGNIAQBkaAAA
AABkaAAAAABkaLWyemYGFmimWlsAAAwVaBRv6AAWaMdfsQAAJQAIgRZof1gBABdoE2RnAGNI
AQBkaAAAAABkaAAAAABkaAWzemYTAQiBBEgBAAVoBrN6ZhZoE2RnAAYWaH9YAQAAJQAIgRZo
x1+xABdofApbAGNIAQBkaAAAAABkaAAAAABkaGizemYTAQiBBEgBAAVoaLN6ZhZofApbAAYW
aMdfsQAABhZoW3W3AAAGFmh4Dv0ALFZaAABcWgAAZFoAAGtaAABxWgAAcloAAKlaAACrWgAA
r1oAALBaAAC2WgAAt1oAAL1aAADnWgAA7VoAAPRaAAD2WgAAIVsAACpbAABRWwAAV1sAAFxb
AAC8WwAA3FsAABNcAAAbXAAAW10AAF1dAADLXQAA0F0AANVdAADaXQAA4l0AAOzi2NTQ1L3U
qpfUjdSXg9R/dH9hjX9df3R/1H/QUtBSFRVoaGHSABZof1gBAEIqBnBo/2YAAAYWaBIb7wAA
JQAIgRZoplpbABdo62FbAGNIAQBkaAAAAABkaAAAAABkaLayemYVFWhoYdIAFmimWlsAQioG
cGj/ZgAABhZoplpbAAATAQiBBEgBAAVotrJ6ZhZo62FbABMBCIEESAEABWgQs3pmFmgUUncA
JQAIgRZoaGHSABdo62FbAGNIAQBkaAAAAABkaAAAAABkaLayemYlAAiBFmhoYdIAF2gUUncA
Y0gBAGRoAAAAAGRoAAAAAGRoELN6ZiUACIEWaGhh0gAXaBRSdwBjSAEAZGgAAAAAZGgAAAAA
ZGgOs3pmBhZof1gBAAAGFmhoYdIAABMBCIEESAEABWi1snpmFmjrYVsAEwEIgQRIAQAFaA2z
emYWaBRSdwAlAAiBFmhoYdIAF2jrYVsAY0gBAGRoAAAAAGRoAAAAAGRotbJ6ZgAg4l0AAONd
AADpXQAA8F0AAFFeAABSXgAAVl4AAFxeAACCXgAAiF4AAJBeAACXXgAA1l4AANxeAADoXgAA
6V4AAO9eAAD2XgAALl8AAC9fAAAzXwAANV8AAEJfAABDXwAARF8AAExfAABNXwAAiV8AAJNf
AACUXwAAwl8AAMdfAADJXwAA2l8AANxfAAD86d/82/zQ/OnG3/yzqfzp3/zbpaGXjXqleqVv
Z6VcpVylAAAAAAAAAAAAABUVaGhh0gAWaDhTKABCKgZwaP9mAAAPFmg4UygAQioGcGj/ZgAA
FRVoOFMoABZoOFMoAEIqBnBo/2YAACUACIEWaDhTKAAXaBRSdwBjSAEAZGgAAAAAZGgAAAAA
ZGgUs3pmEwEIgQRIAQAFaBSzemYWaBRSdwATAQiBBEgBAAVoE7N6ZhZoFFJ3AAYWaBRv6AAA
BhZoOFMoAAATAQiBBEgBAAVoErN6ZhZoFFJ3ACUACIEWaH9YAQAXaBRSdwBjSAEAZGgAAAAA
ZGgAAAAAZGgSs3pmEwEIgQRIAQAFaBGzemYWaBRSdwAVFWhoYdIAFmh/WAEAQioGcGj/ZgAA
BhZoplpbAAATAQiBBEgBAAVotrJ6ZhZo62FbACUACIEWaH9YAQAXaOthWwBjSAEAZGgAAAAA
ZGgAAAAAZGi2snpmBhZof1gBACIuXwAAL18AADVfAAAQYAAAzGAAAM1gAADSYAAAHGIAALsA
AAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAABlAAAA
AAAAAAAAAAAAsgAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAARAAAa2RZLAIAFiQBFyQBSWYBAAAACNYwAAJt/18CRCOABvICAAAAAAAAAAAAAAAA
AAAAAAAG5SAAAAAAAAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggA
AAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP9h9gNt/wkAABYkAUlmAQAAAGdk1kuSAAkW
ABYkAUlmAQAAAGdk1kuSAEQAAGtk8ysCABYkARckAUlmAQAAAAjWMAACbf9fAkQjgAbyAgAA
AAAAAAAAAAAAAAAAAAAABuUgAAAAAAAAAAAAAAAAAAAAABT2A9cjF/YDAAAY9gMAABrWCAAA
AP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/YfYDbf8AB9xfAADgXwAA
8F8AAA9gAAAQYAAAZGAAAJlgAADLYAAAzGAAAM1gAADRYAAA0mAAAOBgAADhYAAA6WAAAOpg
AABRYQAAdWEAAH5hAADgYQAA9mEAAA5iAAAUYgAAG2IAAB1iAAAeYgAAImIAAChiAAAtYgAA
MWIAAE5iAABSYgAAVmIAAIliAACKYgAAymIAAMtiAADMYgAA0WIAANJiAAD16ubi18/H1+Lm
4r2q5qrmppuml5OIk+KEgHWAdYBxgG1pgGltZW0AAAAGFmhrPIYAAAYWaOwc5gAABhZof1gB
AAAGFmhPLooAABUVaGhh0gAWaLdfuABCKgZwaP9mAAAGFmi3X7gAAAYWaOFexQAAFRVoaGHS
ABZoaGHSAEIqBnBo/2YAAAYWaGhh0gAABhZoIlNKAAAVFWimWlsAFmimWlsAQioGcGj/ZgAA
BhZoplpbAAAlAAiBFmg4UygAF2gUUncAY0gBAGRoAAAAAGRoAAAAAGRoFLN6ZhMBCIEESAEA
BWgUs3pmFmgUUncADxZoazyGAEIqBnBo/2YAAA8WaH9YAQBCKgZwaP9mAAAVFWg4UygAFmg4
UygAQioGcGj/ZgAABhZoFG/oAAAGFmg4UygAABUVaGhh0gAWaDhTKABCKgZwaP9mAAATAQiB
BEgBAAVoFbN6ZhZoFFJ3AAAnHGIAAB1iAAAeYgAAQmIAAMxiAADSYgAAwGUAAMFlAADIZQAA
B2gAALsAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAALEAAAAAAAAAAAAA
AACoAAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAFsAAAAAAAAAAAAAAACoAAAAAAAAAAAAAAAA
nwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAABrZCUtAgAWJAEXJAFJ
ZgEAAAAI1jAAAm3/hANEI4AGFwQAAAAAAAAAAAAAAAAAAAAAAAbAHwAAAAAAAAAAAAAAAAAA
AAAU9gPXIxf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggA
AAD/AAAA/2H2A23/CQAAFiQBSWYBAAAAZ2TWS5IACRYAFiQBSWYBAAAAZ2TWS5IAAAQAAGdk
f1gBAAAEAABnZLdDAwBEAABrZL8sAgAWJAEXJAFJZgEAAAAI1jAAAm3/XwJEI4AG8gIAAAAA
AAAAAAAAAAAAAAAAAAblIAAAAAAAAAAAAAAAAAAAAAAU9gPXIxf2AwAAGPYDAAAa1ggAAAD/
AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/2H2A23/AAnSYgAA1mIAANti
AAC6YwAAwGMAANRjAADVYwAA/GMAAE5kAABSZAAAU2QAAFFlAABSZQAAcGUAAHVlAACVZQAA
m2UAAL1lAADAZQAAwWUAAMdlAADIZQAAymUAABdnAABDZwAASWcAAFBnAABbZwAAaGcAAGxn
AAB7ZwAAxGcAAM9nAADYZwAA8GcAAAZoAAAHaAAACGgAACdoAAAsaAAACGkAABRpAAAbaQAA
I2kAAFtpAAB5aQAA/WkAAA1qAAD88fzp8fzl/OH83dnO3c7d2d3K3fzdxsKvpcKawprCmo/l
wsb8xoTGecaExuHG2QAAABUVaBIb7wAWaMwriABCKgZwaP9mAAAVFWhoYdIAFmjMK4gAQioG
cGj/ZgAAFRVoaGHSABZoEhvvAEIqBnBo/2YAABUVaGhh0gAWaC19tQBCKgZwaP9mAAATAQiB
BEgBAAVot7J6ZhZo62FbACUACIEWaC19tQAXaOthWwBjSAEAZGgAAAAAZGgAAAAAZGi3snpm
BhZoLX21AAAGFmjMK4gAAAYWaH9YAQAAFRVoaGHSABZoCTGLAEIqBnBo/2YAAAYWaE8uigAA
BhZoCTGLAAAGFmhoYdIAAAYWaBIb7wAADxZoaGHSAEIqBnBo/2YAABUVaGhh0gAWaGs8hgBC
KgZwaP9mAAAGFmhrPIYALwdoAAAIaAAAEWgAAIJpAACDaQAAjWkAAGBrAAC7AAAAAAAAAAAA
AAAAsgAAAAAAAAAAAAAAAKkAAAAAAAAAAAAAAABlAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAA
AKkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABEAABrZPEtAgAWJAEXJAFJZgEAAAAI1jAAAm3/hANEI4AGFwQAAAAAAAAAAAAAAAAAAAAA
AAbAHwAAAAAAAAAAAAAAAAAAAAAU9gPXIxf2AwAAGPYDAAAa1ggAAAD/AAAA/xvWCAAAAP8A
AAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/2H2A23/CQAAFiQBSWYBAAAAZ2TWS5IACRYAFiQB
SWYBAAAAZ2TWS5IARAAAa2SLLQIAFiQBFyQBSWYBAAAACNYwAAJt/4QDRCOABhcEAAAAAAAA
AAAAAAAAAAAAAAAGwB8AAAAAAAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2AwAAGtYIAAAA/wAA
AP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP9h9gNt/wAGDWoAAA5qAAAragAA
z2oAANVqAAAFawAAX2sAAGFrAACgawAApmsAAK1rAAASbAAAGGwAAB9sAABObAAAVGwAAFts
AACXbAAAnWwAAKRsAAAfbQAAPW0AAE5tAABQbQAAUW0AAG5tAACybgAA2m4AACJvAAAjbwAA
3nAAAORwAADrcAAA9XAAAPpwAAAdcQAAHnEAAB9xAAAucQAAN3EAANBxAADUcQAA2HEAANtx
AAB5cgAA/Pj8+Pz4/PTh1/Th1/Th1/Th1/TT9NPJ0/TF0/S6n5C6iLr0+IR9hHSEdIQAAAAA
AAAAABAVaFBuKQAWaO965AAwShMAAAwVaNkMdAAWaO965AAABhZo73rkAAAPFmhbdbcAQioG
cGj/ZgAAHAEIgQRIAQAFaLeyemYWaOthWwBCKgZwaP9mAAAANAAIgRVomGQaABZoIlNKABdo
62FbAEIqBmNIAQBkaAAAAABkaAAAAABkaLeyemZwaP9mAAAAFRVomGQaABZoIlNKAEIqBnBo
/2YAAAYWaJhkGgAAEwEIgQRIAQAFaCizemYWaN0O9wAGFmgtfbUAABMBCIEESAEABWi3snpm
FmjrYVsAJQAIgRZoIlNKABdo62FbAGNIAQBkaAAAAABkaAAAAABkaLeyemYGFmgiU0oAAAYW
aE8uigAABhZozCuIACxgawAAYWsAAGdrAABebAAAI28AAB1xAAAecQAAH3EAADhxAAAZcwAA
uwAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAKkA
AAAAAAAAAAAAAABlAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAFgAAAAAAAAAAAAAAABTAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdk73rkAAgCAAomAAtGAABnZO965AAABAAAZ2RPLooA
RAAAa2S9LgIAFiQBFyQBSWYBAAAACNYwAAJt/4QDRCOABhcEAAAAAAAAAAAAAAAAAAAAAAAG
wB8AAAAAAAAAAAAAAAAAAAAAFPYD1yMX9gMAABj2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA
/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP9h9gNt/wkAABYkAUlmAQAAAGdk1kuSAAkWABYkAUlm
AQAAAGdk1kuSAEQAAGtkVy4CABYkARckAUlmAQAAAAjWMAACbf+EA0QjgAYXBAAAAAAAAAAA
AAAAAAAAAAAABsAfAAAAAAAAAAAAAAAAAAAAABT2A9cjF/YDAAAY9gMAABrWCAAAAP8AAAD/
G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/YfYDbf8ACXlyAAB9cgAAgXIAALBy
AACycgAAu3IAAMByAADCcgAAy3IAABJzAAAUcwAAF3MAAIRzAACIcwAAjHMAANNzAADbcwAA
HnQAADB0AAB2dAAAgnQAAJB0AACYdAAAEHUAABR1AAAmdQAAKnUAAER1AABFdQAAb3UAAHB1
AAC0dQAAtnUAALd1AAAWeAAAF3gAABl4AABBeAAAR3gAAE54AABWeAAAXHgAAGN4AADveAAA
8HgAABd6AAAjegAAjXoAAJN6AABZewAA7OLe2M/e2M/e2M/e7OLez97P3s/ez97P3s/ey8TA
y7zLuMu8uKWbuKWbuJe4jLiXuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVFWho
YdIAFmgYQFYAQioGcGj/ZgAABhZoaGHSAAATAQiBBEgBAAVouLJ6ZhZo62FbACUACIEWaBhA
VgAXaOthWwBjSAEAZGgAAAAAZGgAAAAAZGi4snpmBhZoGEBWAAAGFmhbdbcAAAYWaHkelAAA
DBVoW3W3ABZo5zErAAAGFmjnMSsAABAVaFBuKQAWaO965AAwShMAAAoWaO965AAwShMAAAYW
aO965AAAEwEIgQRIAQAFaJqyemYWaO51cwAlAAiBFmjveuQAF2judXMAY0gBAGRoAAAAAGRo
AAAAAGRomrJ6ZgAxGXMAABpzAAAtcwAARHUAAEV1AABvdQAAcHUAALV1AAC2dQAAF3gAABh4
AAAZeAAA8HgAAFl7AABIfQAAjn4AAEF/AABCfwAAhIAAAIWAAAAzggAAnYIAAB+DAACLgwAA
BocAAGOHAAAziAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAA
AAAAAAAAAAAAAOoAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAA
AAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAA
AAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAA
AAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAA
AADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA
4AAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAEAABnZFt1twAABAAAZ2RPLooACAIACiYA
C0YAAGdkW3W3AAAEAABnZO965AAIAgAKJgALRgAAZ2TveuQAABpZewAAX3sAAGZ7AADiewAA
5nsAAOp7AAD7ewAA/3sAAAN8AACEfAAAtnwAALt8AADSfAAA13wAAOd8AADofAAA/HwAABN9
AAAUfQAA1n0AAPZ9AAAifgAAJ34AAEF+AACEfgAAin4AAI1+AACOfgAAnX4AAKB+AACkfgAA
qH4AALV+AAC5fgAAvX4AAOzi3svB3q6k3pnemZGZkd6Zkd6Ngt6C3uzeft5+a8F+WKQAACUA
CIEWaFt1twAXaO51cwBjSAEAZGgAAAAAZGgAAAAAZGiasnpmJQAIgRZoW3W3ABdoFhhyAGNI
AQBkaAAAAABkaAAAAABkaKGyemYGFmhbdbcAABUVaBA0TgAWaPUKEABCKgZwaP9mAAAGFmgQ
NE4AAA8WaPUKEABCKgZwaP9mAAAVFWj1ChAAFmj1ChAAQioGcGj/ZgAAEwEIgQRIAQAFaJqy
emYWaO51cwAlAAiBFmj1ChAAF2judXMAY0gBAGRoAAAAAGRoAAAAAGRomrJ6ZhMBCIEESAEA
BWihsnpmFmgWGHIAJQAIgRZo9QoQABdoFhhyAGNIAQBkaAAAAABkaAAAAABkaKGyemYGFmj1
ChAAABMBCIEESAEABWi4snpmFmjrYVsAJQAIgRZo9QoQABdo62FbAGNIAQBkaAAAAABkaAAA
AABkaLiyemYAIr1+AAC/fgAAx34AAO1+AADzfgAA934AACh/AAA/fwAAQH8AAEF/AABCfwAA
QoAAAGGAAACCgAAA7YAAADaBAABSgQAAboEAAHiBAACSgQAAMoIAADOCAADTggAA74IAAPmC
AAD6ggAAYYMAAH+DAACLgwAAoYMAAKeDAAC9gwAA04MAAPeEAAAJhgAADYYAAPuGAAD/hgAA
J4cAACmHAAA+hwAASIcAAGGHAABjhwAAfIcAADOIAADViAAAoYkAAOmJAADuiQAAwooAAMWK
AAAaiwAAxYsAAMaLAAAfjAAAIIwAAPz49Pjq+Nf40/zT9PzT/NP80/zTz8S8xLzEvMS0qbSp
tKm0qbSptKm0qbSptMS8xKHEvMS8mbyOFRVoRQ97ABZomGQaAEIqBnBo/2YAAA8WaHkelABC
KgZwaP9mAAAPFmgQNE4AQioGcGj/ZgAAFRVoRQ97ABZoW3W3AEIqBnBo/2YAAA8WaFt1twBC
KgZwaP9mAAAPFmiYZBoAQioGcGj/ZgAAFRVoRQ97ABZoeR6UAEIqBnBo/2YAAAYWaBhAVgAA
BhZoYWqVAAAlAAiBFmj1ChAAF2jdDvcAY0gBAGRoAAAAAGRoAAAAAGRoM7N6ZhMBCIEESAEA
BWgys3pmFmjdDvcABhZoEDROAAAGFmj1ChAAAAYWaFt1twA4M4gAAKKJAABGigAAwooAAMaL
AAAgjAAAL48AALmPAAC6jwAA2Y8AANqPAACSkQAA6ZMAAIeVAAB7mAAAfZgAAM6YAAATmQAA
N5kAAFWZAACdmQAAvJkAANyZAAD7mQAA/JkAAC+bAAB4mwAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA
AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+gAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAA
AADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA
5AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOQA
AAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAgAABOkAAAUpAAAZ2RyTZIAAAQAAGdkRQ97AAgBAAomAAtGAABnZEUPewAABAAA
Z2RPLooAABogjAAAI4wAAC6MAAAyjAAANowAALGMAADHjAAA0YwAAPCMAABpjQAAR44AAEuO
AABPjgAAW44AAF+OAABjjgAAc44AAHeOAAB7jgAACo8AACqPAAAujwAAL48AALmPAAC6jwAA
9+zRwuy67PfsuqKTuntsuntsumS6WVFGAAAAAAAAAAAAAAAAAAAAABUVaEUPewAWaO965ABC
KgZwaP9mAAAPFmjveuQAQioGcGj/ZgAAFRVoRQ97ABZoLX21AEIqBnBo/2YAAA8WaKgt7ABC
KgZwaP9mAAAcAQiBBEgBAAVonbJ6ZhZoFhhyAEIqBnBo/2YAAAAuAAiBFmgtfbUAF2gWGHIA
QioGY0gBAGRoAAAAAGRoAAAAAGRonbJ6ZnBo/2YAAAAcAQiBBEgBAAVoobJ6ZhZoFhhyAEIq
BnBo/2YAAAAuAAiBFmgtfbUAF2gWGHIAQioGY0gBAGRoAAAAAGRoAAAAAGRoobJ6ZnBo/2YA
AAAPFmgtfbUAQioGcGj/ZgAAHAEIgQRIAQAFaJyyemYWaBYYcgBCKgZwaP9mAAAANAAIgRVo
RQ97ABZoeR6UABdoFhhyAEIqBmNIAQBkaAAAAABkaAAAAABkaJyyemZwaP9mAAAAFRVoRQ97
ABZoeR6UAEIqBnBo/2YAAA8WaJhkGgBCKgZwaP9mAAAAGLqPAAC9jwAA2I8AANmPAADajwAA
348AAOmPAADvjwAADpAAABmQAAA6kAAARpAAAGWQAACokAAArpAAAAeRAAAJkQAAMZEAADmR
AABhkQAAkZEAAJKRAACWkQAA7JEAAO2RAADvkQAAAJIAAA2SAAASkgAAMZIAAFKSAABckgAA
zpIAAIGUAAAilQAAJpUAAC6VAABBlQAAbpUAAHuVAAB+lQAAg5UAAOzZw7+3r7ent6e3p5+3
n7eUp5SMgb99v315fXm/fXW/cW1xbXFtcW1xAAAAAAAAAAAABhZoYWqVAAAGFmgeDCAAAAYW
aNYe9gAABhZo7BzmAAAGFmhFD3sAABUVaEUPewAWaJhkGgBCKgZwaP9mAAAPFmhFD3sAQioG
cGj/ZgAAFRVoRQ97ABZoRQ97AEIqBnBo/2YAAA8WaFt1twBCKgZwaP9mAAAPFmiYZBoAQioG
cGj/ZgAADxZoLX21AEIqBnBo/2YAAA8WaOwc5gBCKgZwaP9mAAAGFmiYZBoAACsACIEVaKd/
0gAWaE8uigAXaIdGvQBjSAEAZGgAAAAAZGgAAAAAZGhcs3pmJQAIgRZoTy6KABdoh0a9AGNI
AQBkaAAAAABkaAAAAABkaFyzemYlAAiBFmhFD3sAF2iHRr0AY0gBAGRoAAAAAGRoAAAAAGRo
XLN6ZgApg5UAAIeVAACjlQAA1JUAAEyWAAB6lgAAfpYAAIKWAACIlgAA/pYAAASXAAAFlwAA
DJcAACuXAABRlwAAU5cAAGeXAACslwAArZcAAOiXAAB7mAAAfJgAAH2YAACImAAAzpgAANqY
AADrmAAAEpkAABOZAAA3mQAARZkAAFSZAABZmQAAXJkAAGWZAACcmQAArpkAALuZAADOmQAA
25kAAOyZAAD6mQAA/JkAAC+bAABDmwAAXJsAAHibAAB+mwAAgJsAAPz49Pjw3dPwz8vPw8/L
z8v8y8+/z/i3w8/0s8+zz/TPqZb0z/TP9M/0z8uSjpKDewAADhZoL1Q8AE9KBABRSgQAABQV
aC9UPAAWaPkFQwBPSgQAUUoEAAAGFmgvVDwAAAYWaPkFQwAAJQAIgRZoTiU6ABdoyW2JAGNI
AQBkaAAAAABkaAAAAABkaDuzemYTAQiBBEgBAAVoObN6ZhZoyW2JAAYWaBA0TgAADxVoHgwg
ABZoHgwgADYIgQYWaFt1twAADxVoHgwgABZoTiU6ADYIgQYWaB4MIAAABhZoTiU6AAATAQiB
BEgBAAVonbJ6ZhZoFhhyACUACIEWaMEGlAAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGidsnpm
BhZowQaUAAAGFmieIsUAAAYWaOwc5gAABhZopzRhADB4mwAAlZsAALGbAADUmwAA9ZsAABec
AAAinAAAP5wAAEGcAABKnAAA2ZwAAIadAACHnQAAk54AAJSeAAAGnwAARZ8AAGufAAB7nwAA
np8AAMOfAADTnwAA+J8AAAmgAAAyoAAAZaAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA
9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA
AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAA
AAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA
AAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAA
AAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAA
AAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAIAAATpAAAFKQAAGdkck2SAAAEAABnZEUPewAACAAAE6QAABSkAABnZC9U
PAAAGYCbAADFmwAAyJsAANGbAAADnAAAFpwAABecAAAinAAAO5wAAEqcAABVnAAAdJwAAMic
AADNnAAA2JwAANmcAADnnAAAWp0AAIOdAACFnQAAhp0AAIedAADinQAA+p0AACSeAABungAA
kp4AAJSeAAAFnwAABp8AABKfAAAsnwAAcJ8AAHifAAB6nwAAyJ8AANCfAADSnwAA/p8AAPXn
zfXC9cK6wraytqe2o7Kfsp+ym5+ytrKbl4+Hn4OfcGafcGafAAAAAAAAAAAAABMBCIEESAEA
BWhFs3pmFmjJbYkAJQAIgRZock2SABdoyW2JAGNIAQBkaAAAAABkaAAAAABkaEWzemYGFmiT
IYEAAA8VaE0i9wAWaNZLkgA2CIEPFWhNIvcAFmhyTZIANgiBBhZo1kuSAAAGFminNGEAAAYW
aHJNkgAABhZo+QVDAAAVFWhpXBoAFmgvVDwAQioGcGj/ZgAABhZoaVwaAAAGFmgvVDwAAA4W
aGlcGgBPSgQAUUoEAAAUFWgvVDwAFmgvVDwAT0oEAFFKBAAAMwAIgRVoL1Q8ABZo+QVDABdo
yW2JAE9KBABRSgQAY0gBAGRoAAAAAGRoAAAAAGRoO7N6ZhsBCIEESAEABWg6s3pmFmjJbYkA
T0oEAFFKBAAUFWgvVDwAFmj5BUMAT0oEAFFKBAAm/p8AAAagAAAIoAAAdaAAAI2gAACcoAAA
vKAAAL2gAAAFoQAADaEAAA+hAACeoQAAo6EAAKuhAACtoQAAHaIAAC+iAABLogAAUaIAAFSi
AACiogAAo6IAAMmiAADKogAAm6MAAKWjAADTowAA1KMAANqjAADcowAAsqQAAPCkAAAtpQAA
M6UAAKelAACopQAAqaUAANulAABEpgAARqYAAKCmAADQpgAA1KYAANumAAD3pgAAIKcAACSn
AACLpwAAnKcAAJ+nAACqpwAA7OLe2t7a3trH4tretKrept7a3tqi2qLantqe2prantqWkqaO
pp6mnqaWpp6miqaKf4oVFWiRamcAFmiRamcAQioGcGj/ZgAABhZokWpnAAAGFmieIsUAAAYW
aF9FtAAABhZoaVwaAAAGFmilR3kAAAYWaKc0YQAABhZoL1Q8AAAGFmhNIvcAABMBCIEESAEA
BWhEs3pmFmjJbYkAJQAIgRZock2SABdoyW2JAGNIAQBkaAAAAABkaAAAAABkaESzemYlAAiB
FmiTIYEAF2jJbYkAY0gBAGRoAAAAAGRoAAAAAGRoQ7N6ZgYWaJMhgQAABhZock2SAAATAQiB
BEgBAAVoQ7N6ZhZoyW2JACUACIEWaHJNkgAXaMltiQBjSAEAZGgAAAAAZGgAAAAAZGhDs3pm
ADJloAAAjqAAAI+gAACQoAAAvaAAAM+gAAD/oAAAEKEAADyhAAByoQAAnqEAAK6hAADkoQAA
GKIAAFSiAABVogAAVqIAAIajAACHowAAYaQAAGKkAACopQAAqaUAAKyoAACtqAAArqgAAO4A
AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADcAAAA
AAAAAAAAAAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA3AAAAAAA
AAAAAAAAANwAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAA
AAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAA
AAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAA
AOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAAAA
AAQAAGdkRQ97AAAIAAATpAAAFKQAAGdkkyGBAAAIAAATpAAAFKQAAGdkck2SABEAABOkAAAU
pAAAJmQGAQABUMYIAAAA/wYBAQBnZHJNkgAAGaqnAACrpwAArqcAALmnAABOqAAAq6gAAK2o
AACuqAAAtagAAOeoAADoqAAA9agAAPqoAABNqQAAUqkAAKSpAABUqgAAVqoAALyqAADFqgAA
0KoAAIyrAACwqwAA1qsAABCsAAAUrAAAFawAAIKuAAD5rgAA+q4AAJ2vAACvrwAAs68AAMav
AAAzsAAANLAAADewAAA4sAAAQbAAAEOwAABesAAAJrEAAEexAACQsQAAlLEAANWxAAD/sQAA
TrIAAHuyAACAsgAAxbIAAO6yAAD+sgAAHbMAADWzAABJswAA/PH87en85eDY0PzM/Mz8yOnI
zMTIwMjEyLzIuMjpremt6fzgqKObo5e4l8CXwJfAk5fEl+mXjwAAAAAAAAAGFmh1HnAAAAYW
aNl6UQAABhZocWOaAAAPFWhNIvcAFmhxY5oANgiBCRZocWOaADYIgQkWaF9FtAA2CIEVFWhp
XBoAFmhpXBoAQioGcGj/ZgAABhZopzRhAAAGFmhfRbQAAAYWaCphHwAABhZoqC3sAAAGFmjr
UUUAAAYWaC19tQAADxVopzRhABZoTSL3ADYIgQ8VaE0i9wAWaE0i9wA2CIEJFmhpXBoANgiB
BhZokyGBAAAGFmhpXBoAAAYWaJ4ixQAAFRVokWpnABZoTSL3AEIqBnBo/2YAAAYWaE0i9wA3
rqgAAK+oAACwqAAAsagAALKoAACzqAAAtKgAALWoAADoqAAA9agAAAypAAAdqQAAK6kAAD2p
AAA+qQAAP6kAAE2pAABkqQAAcqkAAISpAACSqQAApKkAAKWpAAAnqgAAKKoAAM6qAADPqgAA
+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA
AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADxAAAA
AAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA4AAAAAAA
AAAAAAAAAOAAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA
AAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAA
AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA
APEAAAAAAAAAAAAAAAAAABEAABOkAAAUpAAAJmQGAQABUMYIAAAA/wYBAQBnZOtRRQAACAAA
E6QAABSkAABnZOtRRQAABAAAZ2RFD3sAABrPqgAAFKwAABWsAAAcrQAAHa0AAPquAAD7rgAA
M7AAADSwAAA1sAAANrAAADewAAA4sAAAXrAAAFOxAABUsQAAYrEAAHCxAACOsQAA1bEAAP+x
AAANsgAAK7IAAE6yAAB7sgAAs7IAALSyAAC8tAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA
AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA
9gAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA
AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAA
AAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAA
AAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAA
AAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAA
AAAAAAAIAAATpAAAFKQAAGdkcWOaAAAEAABnZEUPewAACAAAE6QAABSkAABnZOtRRQAAG0mz
AABMswAAVLMAAJuzAAC1swAAx7MAAOWzAAAetAAAQrQAAE+0AAC7tAAAvbQAAAK1AAA6tQAA
PLUAACi2AAAutgAAjLYAAI22AABwtwAASrgAAEu4AABMuAAAULgAAIi4AABKugAAUboAAFK6
AAC0ugAAwLoAAMS6AADQugAA8LoAAPG6AADZuwAA3bsAAB+8AABBvAAAfLwAAAW9AAAGvQAA
B70AACa9AAC3vQAA9L4AAPi+AACuvwAAsL8AAE7AAAB0wAAAgMAAAKLAAAC2wAAAG8EAAPfz
7+vn6+fj5+vn7+fv59/n7+fb59vj09vIwNvI28i82/O48+PzuLSvp6OfjJ/jn+Of45+IAAAA
BhZo73rkAAAlAAiBFmhbWooAF2iHRr0AY0gBAGRoAAAAAGRoAAAAAGRoXbN6ZgYWaFtaigAA
BhZoniLFAAAPFWieIsUAFmieIsUAXAiBCRZodR5wAFwIgQYWaJFqZwAABhZoA3DxAAAGFmgv
VDwAAA8WaKVHeQBCKgZwaP9mAAAVFWilR3kAFmilR3kAQioGcGj/ZgAADxVopUd5ABZopUd5
ADYIgQYWaKVHeQAABhZopzRhAAAGFmhpXBoAAAYWaCphHwAABhZo2XpRAAAGFmhxY5oAAAYW
aHUecAAADxVoaVwaABZodR5wADYIgQA1vLQAAL20AAA7tQAAPLUAAEm1AABntQAArrUAANm1
AADntQAABbYAACi2AABgtgAAjLYAAI22AABLuAAATLgAAE24AABOuAAAT7gAAFC4AACIuAAA
5LkAAOW5AAD3uQAABboAABy6AAAqugAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAA
AAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAA
AAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAA
AAAAAADtAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAA
AAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAA
AOgAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADf
AAAAAAAAAAAAAAAA3wAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAAAACAAAE6QAABSkAABnZKVH
eQAABAAAZ2RFD3sAAAgAABOkAAAUpAAAZ2QqYR8AAAgAABOkAAAUpAAAZ2RxY5oAABoqugAA
OboAADq6AADxugAA8roAAAa9AAAHvQAAJr0AACTBAACowgAAqcIAAKrCAACrwgAArMIAAK3C
AACvwgAA58QAAKzFAAAxxgAAS8YAAHnGAADVxwAAIMkAAC7KAAD2AAAAAAAAAAAAAAAA8QAA
AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOkAAAAA
AAAAAAAAAADpAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADcAAAAAAAA
AAAAAAAA3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA3AAAAAAAAAAA
AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA
AADUAAAAAAAAAAAAAAAAzAAAAAAAAAAAAAAAAMoAAAAAAAAAAAAAAADKAAAAAAAAAAAAAAAA
ygAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAIAgAKJgALRgAAZ2TveuQACAEACiYAC0YAAGdk
73rkAA0AACZkBgEAAVDGCAAAAP8GAQEAZ2RFD3sACAIACiYAC0YAAGdkniLFAAAEAABnZEUP
ewAACAAAE6QAABSkAABnZKVHeQAAFxvBAAAjwQAAJMEAAKTBAABNwgAAUMIAAKfCAACowgAA
qcIAAK3CAACvwgAAsMIAAEHFAABLxQAAq8UAAL7FAADHxQAABMYAAC/GAAAwxgAAMcYAADTG
AABLxgAAT8YAAG/GAABzxgAAd8YAAKLGAACmxgAAqsYAALfGAADXxgAAasgAAHjIAACZyAAA
ncgAAKHIAAD6yAAA/sgAAALJAABwyQAAdMkAAHjJAACsyQAA/Pj08Obw9Pji3tbLw8vWw9a7
1su3sLesmY+smY+si6yLrHhurHhurHhurAATAQiBBEgBAAVonrJ6ZhZoFhhyACUACIEWaLFK
ZgAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGiesnpmBhZoZyeQAAATAQiBBEgBAAVonbJ6ZhZo
FhhyACUACIEWaLFKZgAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGidsnpmBhZosUpmAAAMFWin
f9IAFmixSmYAAAYWaO965AAADxZo2XpRAEIqBnBo/2YAAA8WaF9FtABCKgZwaP9mAAAVFWiR
amcAFmiRamcAQioGcGj/ZgAADxZokWpnAEIqBnBo/2YAAAYWaFtaigAABhZoX0W0AAATAQiB
BEgBAAVoXrN6ZhZoh0a9AAYWaHUecAAABhZopzRhAAAGFmjZelEAAAYWaGlcGgArrMkAALDJ
AAC0yQAAEMoAABTKAAAYygAAPMoAAEDKAABEygAAEM0AABTNAAAzzQAAN80AADvNAAAFzgAA
Bs4AADvOAAA8zgAAX84AAGDOAAB/zgAAgM4AADrQAAA/0AAAe9AAAJzQAACv0AAAuNAAAAPR
AAAH0QAAV9MAAF/TAADU0wAA2NMAAD/VAABD1QAAR9UAAHfVAACC1QAAg9UAAC3WAAAx1gAA
NdYAAHzWAADW1gAA2tYAAN7WAADg1gAA4dYAAO/XAADy1wAA+tcAABjYAADs4t7s4t7s4t7a
3uzi3tPe097T3tPez97P3s/e2t7L3sfe7OLex8DPraPPn4yjn8/en4ifAAAAAAAAAAAGFmg7
AmEAACUACIEWaO5soAAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGifsnpmBhZo7mygAAATAQiB
BEgBAAVon7J6ZhZoFhhyACUACIEWaGcnkAAXaBYYcgBjSAEAZGgAAAAAZGgAAAAAZGifsnpm
DBVop3/SABZosUpmAAAGFmjveuQAAAYWaLdDAwAABhZoZyeQAAAMFWhuZvkAFmixSmYAAAYW
aNl6UQAABhZosUpmAAATAQiBBEgBAAVonrJ6ZhZoFhhyACUACIEWaLFKZgAXaBYYcgBjSAEA
ZGgAAAAAZGgAAAAAZGiesnpmADQuygAA8coAAI3LAAAQzQAAPc0AAOHNAAAGzgAAPM4AAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAAqwAAAAAAAAAAAAAAAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJ
GAAKJgALRggARcaAAQABAGWyemYAAAAAAAAAAAAXFxcXFxcXFxcAAAoAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAt/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZG5m+QAASRgACiYAC0YIAEXGgAEA
AQBlsnpmAAAAAAAAAAAAFxcXFxcXFxcXAAAJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABALfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAZ2RuZvkACAIACiYAC0YAAGdk2XpRAAABAAAABzzOAABgzgAA
gM4AAKjPAAAD0QAAJdEAANTTAAD10wAAd9UAAIPVAADh1gAAtQAAAAAAAAAAAAAAAGsAAAAA
AAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAGEAAAAAAAAAAAAAAABpAAAAAAAA
AAAAAAAAYQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABZAAAAAAAAAAAAAAAAaQAAAAAAAAAA
AAAAAAAAAAAIAQAKJgALRgAAZ2TveuQACAIACiYAC0YAAGdk73rkAAABAAAASRgACiYAC0YI
AEXGgAEAAQBlsnpmAAAAAAAAAAAAFxcXFxcXFxcXAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAABALfwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2RuZvkAAEkYAAomAAtGCABFxoABAAEAZbJ6ZgAA
AAAAAAAAABcXFxcXFxcXFwAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQC38AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAGdkbmb5AAAKGNgAAB7YAAAw2AAANdgAADnYAACh2AAAotgAAKPYAACr2AAA
rNgAAMLYAADD2AAAxNgAAMXYAAC12QAAttkAAMrZAADM2QAA09kAANTZAADX2QAA2tkAAATa
AAAF2gAAEtoAABPaAAAV2gAAOdoAADraAAA82gAAZtoAAGfaAABp2gAAldoAAJbaAACY2gAA
w9oAAMTaAADG2gAA89oAAPTaAAD22gAAIdsAACLbAAAk2wAAR9sAAEjbAABK2wAAcNsAAHHb
AABz2wAAndsAAJ7bAACg2wAAx9sAAMjbAADK2wAA8tsAAPPbAAD12wAAINwAACHcAAAj3AAA
UdwAAFLcAABU3AAAgdwAAILcAACE3AAAvNwAAL3cAAC/3AAA+NwAAPncAAD38/fs8+jg3NTc
1MvU3OjH88fzx/PHw77DusfDusfDusfDusfDusfDusfDusfDusfDusfDusfDusfDusfDusfD
usfDusfDusfDAAAABhZo9Wl5AAAJFmixSmYANQiBBhZoYwwpAAAGFmixSmYAABEWaD1+OABt
SAAEbkgABHUIAQ8DagAAAAAWaDsCYQBVCAEGFmg7AmEAAA8DaiMvAgAWaI8omABVCAEGFmh1
S3sAAAwVaO5soAAWaO5soAAABhZo7mygAAAQFWhQbikAFmjubKAAMEoTAEnh1gAAotgAAKTY
AAC22QAA19kAANjZAADZ2QAA2tkAAOrZAADx2QAA9tkAAP7ZAAAE2gAA/QAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAA
AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2RZLzkAAAQXAGdkOwJhAAYA
AAYkAWdkOwJhAAABAAAADATaAAAF2gAAEtoAAFoAAAAAAAAAAAAAAABNAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAANAAADJAETpAAAFKQAABYkAUlmAQAAAGEkAaUAAGtkaDcCABYkARckAUlmAQAA
AABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCMA
BpILAAAAAAAAAAAEAQAAAAAAAAAGKQUAAAAAAAAAAAQBAAAAAAAAAAYMBgAAAAAAAAAABAEA
AAAAAAAABpQEAAAAAAAAAAAEAQAAAAAAAAAG5gcAAAAAAAAAAAQBAAAAAAAAE9YwAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/
AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/
AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAACEtoAABPaAAAn2gAA
LNoAADXaAAA32gAAOdoAAKYAAAAAAAAAAAAAAACdAAAAAAAAAAAAAAAAlAAAAAAAAAAAAAAA
AJQAAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZFkvOQAJFgAWJAFJZgEAAABnZFBuKQBZAABr
ZE44AgAWJAEXJAFJZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAAB5S1/gjW
GgAB+/88IwAGQSMEAQAAAAAAAAQBAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA
AAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQA
AAD/YfYDAACKVAEAAAY52gAAOtoAAE/aAABX2gAAYtoAAGTaAABm2gAAWgAAAAAAAAAAAAAA
AFEAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABI
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAW
JAFJZgEAAABnZFkvOQAJFgAWJAFJZgEAAABnZFBuKQClAABrZNw4AgAWJAEXJAFJZgEAAAAA
VAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAAB5S1/gjWcgAF+/+NC7YQwhZWGzwjAAaS
CwQBAAAAAAAAAAAAAAAAAAAABikFBAEAAAAAAAAAAAAAAAAAAAAGDAYEAQAAAAAAAAAAAAAA
AAAAAAaUBAQBAAAAAAAAAAAAAAAAAAAABuYHBAEAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAA
AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAGtYUAAAA/wAA
AP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAA
AP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP9h9gMAAIpUAQAABmbaAABn2gAAfNoAAIba
AACR2gAAk9oAAJXaAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABI
AAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdk
UG4pAKUAAGtkwjkCABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAA
AAAHlLX+CNZyAAX7/40LthDCFlYbPCMABpILAAAAAAAAAAAAAAAAAAAAAAAGKQUAAAAAAAAA
AAAAAAAAAAAAAAYMBgAAAAAAAAAAAAAAAAAAAAAABpQEAAAAAAAAAAAAAAAAAAAAAAAG5gcA
AAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/
AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA
/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA
/2H2AwAAilQBAAAGldoAAJbaAACr2gAAtNoAAL/aAADB2gAAw9oAAFoAAAAAAAAAAAAAAABR
AAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQB
SWYBAAAAZ2RZLzkACRYAFiQBSWYBAAAAZ2RQbikApQAAa2SaOgIAFiQBFyQBSWYBAAAAAFQB
AAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8IwAGkgsA
AAAAAAAAAAAAAAAAAAAAAAYpBQAAAAAAAAAAAAAAAAAAAAAABgwGAAAAAAAAAAAAAAAAAAAA
AAAGlAQAAAAAAAAAAAAAAAAAAAAAAAbmBwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/
AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/
AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAAbD2gAAxNoAANraAADj2gAA
79oAAPHaAADz2gAAWgAAAAAAAAAAAAAAAFEAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAA
AAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZFkvOQAJFgAWJAFJZgEAAABnZFBu
KQClAABrZHI7AgAWJAEXJAFJZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAA
B5S1/gjWcgAF+/+NC7YQwhZWGzwjAAaSCwAAAAAAAAAAAAAAAAAAAAAABikFAAAAAAAAAAAA
AAAAAAAAAAAGDAYAAAAAAAAAAAAAAAAAAAAAAAaUBAAAAAAAAAAAAAAAAAAAAAAABuYHAAAA
AAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAA
AAAAAAD/AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8A
AAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP9h
9gMAAIpUAQAABvPaAAD02gAACtsAABPbAAAd2wAAH9sAACHbAABaAAAAAAAAAAAAAAAAUQAA
AAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlm
AQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtkSjwCABYkARckAUlmAQAAAABUAQAF
1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCOABpILAAAA
AAAAAAAAAAAAAAAAAAAGKQUAAAAAAAAAAAAAAAAAAAAAAAYMBgAAAAAAAAAAAAAAAAAAAAAA
BpQEAAAAAAAAAAAAAAAAAAAAAAAG5gcAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAA
AP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAA
AP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAGIdsAACLbAAAz2wAAO9sAAEPb
AABF2wAAR9sAAFoAAAAAAAAAAAAAAABRAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAA
AAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2RZLzkACRYAFiQBSWYBAAAAZ2RQbikA
pQAAa2QoPQIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeU
tf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAAAAAAAAAAAAAYpBQAAAAAAAAAAAAAA
AAAAAAAABgwGAAAAAAAAAAAAAAAAAAAAAAAGlAQAAAAAAAAAAAAAAAAAAAAAAAbmBwAAAAAA
AAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAA
AAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA
/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYD
AACKVAEAAAZH2wAASNsAAFrbAABj2wAAbNsAAG7bAABw2wAAWgAAAAAAAAAAAAAAAFEAAAAA
AAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEA
AABnZFkvOQAJFgAWJAFJZgEAAABnZFBuKQClAABrZAY+AgAWJAEXJAFJZgEAAAAAVAEABdYY
BAEAAAQBAAAEAQAABAEAAAAAAAAAAAAAB5S1/gjWcgAF+/+NC7YQwhZWGzwjgAaSCwAAAAAA
AAAAAAAAAAAAAAAABikFAAAAAAAAAAAAAAAAAAAAAAAGDAYAAAAAAAAAAAAAAAAAAAAAAAaU
BAAAAAAAAAAAAAAAAAAAAAAABuYHAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/
AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/
HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP9h9gMAAIpUAQAABnDbAABx2wAAhNsAAI/bAACZ2wAA
m9sAAJ3bAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAA
AAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUA
AGtk5D4CABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+
CNZyAAX7/40LthDCFlYbPCOABpILAAAAAAAAAAAAAAAAAAAAAAAGKQUAAAAAAAAAAAAAAAAA
AAAAAAYMBgAAAAAAAAAAAAAAAAAAAAAABpQEAAAAAAAAAAAAAAAAAAAAAAAG5gcAAAAAAAAA
AAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAA
AP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8A
AAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAA
ilQBAAAGndsAAJ7bAACx2wAAudsAAMPbAADF2wAAx9sAAFoAAAAAAAAAAAAAAABRAAAAAAAA
AAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAA
Z2RZLzkACRYAFiQBSWYBAAAAZ2RQbikApQAAa2TCPwIAFiQBFyQBSWYBAAAAAFQBAAXWGAQB
AAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAA
AAAAAAAAAAAAAAYpBQAAAAAAAAAAAAAAAAAAAAAABgwGAAAAAAAAAAAAAAAAAAAAAAAGlAQA
AAAAAAAAAAAAAAAAAAAAAAbmBwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAA
AAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAA
AP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3W
FAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAAbH2wAAyNsAANzbAADj2wAA7tsAAPDb
AADy2wAAWgAAAAAAAAAAAAAAAFEAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAA
AAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZFkvOQAJFgAWJAFJZgEAAABnZFBuKQClAABr
ZKBAAgAWJAEXJAFJZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAAB5S1/gjW
cgAF+/+NC7YQwhZWGzwjgAaSCwAAAAAAAAAAAAAAAAAAAAAABikFAAAAAAAAAAAAAAAAAAAA
AAAGDAYAAAAAAAAAAAAAAAAAAAAAAAaUBAAAAAAAAAAAAAAAAAAAAAAABuYHAAAAAAAAAAAA
AAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/
AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8AAAD/AAAA
/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP9h9gMAAIpU
AQAABvLbAADz2wAACNwAABHcAAAc3AAAHtwAACDcAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAA
AAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdk
WS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtkfkECABYkARckAUlmAQAAAABUAQAF1hgEAQAA
BAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCOABpILAAAAAAAAAAAA
AAAAAAAAAAAGKQUAAAAAAAAAAAAAAAAAAAAAAAYMBgAAAAAAAAAAAAAAAAAAAAAABpQEAAAA
AAAAAAAAAAAAAAAAAAAG5gcAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAA
AP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/
AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQA
AAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAGINwAACHcAAA23AAAQtwAAE3cAABP3AAA
UdwAAFoAAAAAAAAAAAAAAABRAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAA
AABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2RZLzkACRYAFiQBSWYBAAAAZ2RQbikApQAAa2Rc
QgIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIA
Bfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAAAAAAAAAAAAAYpBQAAAAAAAAAAAAAAAAAAAAAA
BgwGAAAAAAAAAAAAAAAAAAAAAAAGlAQAAAAAAAAAAAAAAAAAAAAAAAbmBwAAAAAAAAAAAAAA
AAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAA
AAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c
1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEA
AAZR3AAAUtwAAGfcAABy3AAAfdwAAH/cAACB3AAAWgAAAAAAAAAAAAAAAFEAAAAAAAAAAAAA
AABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZFkv
OQAJFgAWJAFJZgEAAABnZFBuKQClAABrZDpDAgAWJAEXJAFJZgEAAAAAVAEABdYYBAEAAAQB
AAAEAQAABAEAAAAAAAAAAAAAB5S1/gjWcgAF+/+NC7YQwhZWGzwjgAaSCwAAAAAAAAAAAAAA
AAAAAAAABikFAAAAAAAAAAAAAAAAAAAAAAAGDAYAAAAAAAAAAAAAAAAAAAAAAAaUBAAAAAAA
AAAAAAAAAAAAAAAABuYHAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/
BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAA
AP8b1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA
/wAAAP8AAAD/AAAA/wAAAP9h9gMAAIpUAQAABoHcAACC3AAAmNwAAKPcAACv3AAAsdwAALzc
AABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAA
SAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtkGEQC
ABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7
/40LthDCFlYbPCOABpILAAAAAAAAAAAAAAAAAAAAAAAGKQUAAAAAAAAAAAAAAAAAAAAAAAYM
BgAAAAAAAAAAAAAAAAAAAAAABpQEAAAAAAAAAAAAAAAAAAAAAAAG5gcAAAAAAAAAAAAAAAAA
AAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAA
FPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYU
AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAG
vNwAAL3cAADT3AAA3twAAOvcAADt3AAA+NwAAFoAAAAAAAAAAAAAAABRAAAAAAAAAAAAAAAA
SAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2RZLzkA
CRYAFiQBSWYBAAAAZ2RQbikApQAAa2T2RAIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAA
BAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAAAAAAA
AAAAAAYpBQAAAAAAAAAAAAAAAAAAAAAABgwGAAAAAAAAAAAAAAAAAAAAAAAGlAQAAAAAAAAA
AAAAAAAAAAAAAAbmBwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB
AAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/
G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8A
AAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAAb43AAA+dwAAArdAABaAAAAAAAAAAAAAAAATQAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAADQAAAyQBE6QAABSkAAAWJAFJZgEAAABhJAGlAABrZNRFAgAW
JAEXJAFJZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAAB5S1/gjWcgAF+/+N
C7YQwhZWGzwjgAaSCwAAAAAAAAAABAEAAAAAAAAABikFAAAAAAAAAAAEAQAAAAAAAAAGDAYA
AAAAAAAAAAQBAAAAAAAAAAaUBAAAAAAAAAAABAEAAAAAAAAABuYHAAAAAAAAAAAEAQAAAAAA
ABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2
AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xzWFAAA
AP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP9h9gMAAIpUAQAAAvnc
AAAK3QAAC90AAA3dAAA53QAAOt0AADzdAABo3QAAad0AAGvdAACW3QAAl90AAJndAADM3QAA
zd0AAM/dAAAJ3gAACt4AAAzeAAA33gAAON4AADreAABc3gAAXd4AAF/eAACq3gAAq94AAK3e
AADV3gAA1t4AAOXeAADm3gAA6N4AACrfAAAr3wAALd8AAGzfAABt3wAAb98AAKLfAACj3wAA
pd8AAAbgAAAH4AAACeAAAEngAABK4AAAXuAAAF/gAABh4AAAmuAAAJvgAACd4AAA6uAAAOvg
AAAH4QAACOEAAArhAABF4QAARuEAAEjhAABy4QAAc+EAAIDhAACB4QAAg+EAAK/hAACw4QAA
suEAANzhAADd4QAA6uEAAOvhAADt4QAAHuIAAB/iAAAh4gAAQeIAAEriAABR4gAAUuIAAFPi
AABU4gAAVeIAAPr28u728u728u728u728u728u728u728u728u72+vby7vby7vby7vby7vby
7vb69vLu9vLu9vr28u728u72+vby7vby7vb69vLu9vLu5+727uPZAAAAAAAAAAAAAAAAAAAA
EwNqAAAAABZopUd5ADBKEABVCAEGFmgEDaEAAAwVaFkvOQAWaLFKZgAABhZosUpmAAAGFmj1
aXkAAAYWaGMMKQAACRZosUpmADUIgQBTCt0AAAvdAAAa3QAAJN0AACzdAAAu3QAAOd0AAKYA
AAAAAAAAAAAAAACdAAAAAAAAAAAAAAAAlAAAAAAAAAAAAAAAAJQAAAAAAAAAAAAAAACUAAAA
AAAAAAAAAAAAlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAW
JAFJZgEAAABnZFkvOQAJFgAWJAFJZgEAAABnZFBuKQBZAABrZMBGAgAWJAEXJAFJZgEAAAAA
VAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAAB5S1/gjWGgAB+/88I4AGQSMEAQAAAAAA
AAQBAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAA
AP8AAAAAFPYBAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/YfYDAACKVAEAAAY53QAA
Ot0AAEndAABS3QAAW90AAF3dAABo3QAAWgAAAAAAAAAAAAAAAFEAAAAAAAAAAAAAAABIAAAA
AAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZFkvOQAJFgAW
JAFJZgEAAABnZFBuKQClAABrZFRHAgAWJAEXJAFJZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAA
BAEAAAAAAAAAAAAAB5S1/gjWcgAF+/+NC7YQwhZWGzwjgAaSCwQBAAAAAAAAAAAAAAAAAAAA
BikFBAEAAAAAAAAAAAAAAAAAAAAGDAYEAQAAAAAAAAAAAAAAAAAAAAaUBAQBAAAAAAAAAAAA
AAAAAAAABuYHBAEAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA
AP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQA
AAD/AAAA/wAAAP8AAAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8A
AAD/AAAA/wAAAP9h9gMAAIpUAQAABmjdAABp3QAAd90AAIDdAACK3QAAjN0AAJbdAABaAAAA
AAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAA
AAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtkQEgCABYkARck
AUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDC
FlYbPCOABpILAAAAAAAAAAAAAAAAAAAAAAAGKQUAAAAAAAAAAAAAAAAAAAAAAAYMBgAAAAAA
AAAAAAAAAAAAAAAABpQEAAAAAAAAAAAAAAAAAAAAAAAG5gcAAAAAAAAAAAAAAAAAAAAAE9Yw
AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa
1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAA
AP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAGlt0AAJfd
AACk3QAArN0AALjdAAC63QAAzN0AAFoAAAAAAAAAAAAAAABRAAAAAAAAAAAAAAAASAAAAAAA
AAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQBSWYBAAAAZ2RZLzkACRYAFiQB
SWYBAAAAZ2RQbikApQAAa2QeSQIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAABAEAAAQB
AAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAAAAAAAAAAAAAYp
BQAAAAAAAAAAAAAAAAAAAAAABgwGAAAAAAAAAAAAAAAAAAAAAAAGlAQAAAAAAAAAAAAAAAAA
AAAAAAbmBwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/
BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA
/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA
/wAAAP8AAAD/YfYDAACKVAEAAAbM3QAAzd0AANrdAADh3QAA7d0AAO/dAAAJ3gAAWgAAAAAA
AAAAAAAAAFEAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAA
AAAAAABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAJAAAWJAFJZgEAAABnZFkvOQAJFgAWJAFJZgEAAABnZFBuKQClAABrZPxJAgAWJAEXJAFJ
ZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAAB5S1/gjWcgAF+/+NC7YQwhZW
GzwjgAaSCwAAAAAAAAAAAAAAAAAAAAAABikFAAAAAAAAAAAAAAAAAAAAAAAGDAYAAAAAAAAA
AAAAAAAAAAAAAAaUBAAAAAAAAAAAAAAAAAAAAAAABuYHAAAAAAAAAAAAAAAAAAAAABPWMAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAGtYU
AAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xzWFAAAAP8AAAD/
AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP9h9gMAAIpUAQAABgneAAAK3gAA
F94AAB7eAAAq3gAALN4AADfeAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAA
AAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlm
AQAAAGdkUG4pAKUAAGtk2koCABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAA
AAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCOABpILAAAAAAAAAAAAAAAAAAAAAAAGKQUA
AAAAAAAAAAAAAAAAAAAAAAYMBgAAAAAAAAAAAAAAAAAAAAAABpQEAAAAAAAAAAAAAAAAAAAA
AAAG5gcAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB
AAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8A
AAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8A
AAD/AAAA/2H2AwAAilQBAAAGN94AADjeAABB3gAASN4AAFPeAABV3gAAXN4AAFoAAAAAAAAA
AAAAAABRAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAA
AAAASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
CQAAFiQBSWYBAAAAZ2RZLzkACRYAFiQBSWYBAAAAZ2RQbikApQAAa2S4SwIAFiQBFyQBSWYB
AAAAAFQBAAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8
I4AGkgsAAAAAAAAAAAAAAAAAAAAAAAYpBQAAAAAAAAAAAAAAAAAAAAAABgwGAAAAAAAAAAAA
AAAAAAAAAAAGlAQAAAAAAAAAAAAAAAAAAAAAAAbmBwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAA
AP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAA
AP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAAZc3gAAXd4AAGbe
AABx3gAAfd4AAH/eAACq3gAAWgAAAAAAAAAAAAAAAFEAAAAAAAAAAAAAAABIAAAAAAAAAAAA
AAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZFkvOQAJFgAWJAFJZgEA
AABnZFBuKQClAABrZJZMAgAWJAEXJAFJZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAABAEAAAAA
AAAAAAAAB5S1/gjWcgAF+/+NC7YQwhZWGzwjgAaSCwAAAAAAAAAAAAAAAAAAAAAABikFAAAA
AAAAAAAAAAAAAAAAAAAGDAYAAAAAAAAAAAAAAAAAAAAAAAaUBAAAAAAAAAAAAAAAAAAAAAAA
BuYHAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA
AAAA/wAAAAAAAAD/AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA
/wAAAP8AAAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA
/wAAAP9h9gMAAIpUAQAABqreAACr3gAAtN4AAL/eAADL3gAAzd4AANXeAABaAAAAAAAAAAAA
AAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAA
AEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkA
ABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtkdE0CABYkARckAUlmAQAA
AABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCOA
BpILAAAAAAAAAAAAAAAAAAAAAAAGKQUAAAAAAAAAAAAAAAAAAAAAAAYMBgAAAAAAAAAAAAAA
AAAAAAAABpQEAAAAAAAAAAAAAAAAAAAAAAAG5gcAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQB
AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/
AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/
AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAG1d4AANbeAADl3gAA
WgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAMkAROkAAAUpAAAFiQBSWYB
AAAAYSQBpQAAa2RSTgIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAABAEAAAQBAAAAAAAA
AAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAQBAAAAAAAAAAYpBQAAAAAA
AAAABAEAAAAAAAAABgwGAAAAAAAAAAAEAQAAAAAAAAAGlAQAAAAAAAAAAAQBAAAAAAAAAAbm
BwAAAAAAAAAABAEAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA
AP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8A
AAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8A
AAD/YfYDAACKVAEAAALl3gAA5t4AAO/eAAD73gAAB98AABLfAAAq3wAApgAAAAAAAAAAAAAA
AJ0AAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAlAAAAAAAAAAAAAAAAJQAAAAAAAAAAAAAAACU
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdk
WS85AAkWABYkAUlmAQAAAGdkUG4pAFkAAGtkPk8CABYkARckAUlmAQAAAABUAQAF1hgEAQAA
BAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNYaAAH7/zwjgAZBIwQBAAAAAAAABAEAAAAAAAAT
1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEA
ABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP9h9gMAAIpUAQAABirfAAAr3wAANN8AAD/f
AABL3wAAVt8AAGzfAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABI
AAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdk
UG4pAKUAAGtk0k8CABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAA
AAAHlLX+CNZyAAX7/40LthDCFlYbPCOABpILBAEAAAAAAAAAAAAAAAAAAAAGKQUEAQAAAAAA
AAAAAAAAAAAAAAYMBgQBAAAAAAAAAAAAAAAAAAAABpQEBAEAAAAAAAAAAAAAAAAAAAAG5gcE
AQAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/
AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA
/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA
/2H2AwAAilQBAAAGbN8AAG3fAAB33wAAgt8AAI7fAACZ3wAAot8AAFoAAAAAAAAAAAAAAABR
AAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAFiQB
SWYBAAAAZ2RZLzkACRYAFiQBSWYBAAAAZ2RQbikApQAAa2S+UAIAFiQBFyQBSWYBAAAAAFQB
AAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8I4AGkgsA
AAAAAAAAAAAAAAAAAAAAAAYpBQAAAAAAAAAAAAAAAAAAAAAABgwGAAAAAAAAAAAAAAAAAAAA
AAAGlAQAAAAAAAAAAAAAAAAAAAAAAAbmBwAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/
AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/
AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAAai3wAAo98AAK3fAAC43wAA
xN8AAM/fAAAG4AAAWgAAAAAAAAAAAAAAAFEAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAA
AAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZFkvOQAJFgAWJAFJZgEAAABnZFBu
KQClAABrZJxRAgAWJAEXJAFJZgEAAAAAVAEABdYYBAEAAAQBAAAEAQAABAEAAAAAAAAAAAAA
B5S1/gjWcgAF+/+NC7YQwhZWGzwjgAaSCwAAAAAAAAAAAAAAAAAAAAAABikFAAAAAAAAAAAA
AAAAAAAAAAAGDAYAAAAAAAAAAAAAAAAAAAAAAAaUBAAAAAAAAAAAAAAAAAAAAAAABuYHAAAA
AAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAA
AAAAAAD/AAAAABT2AQAAGtYUAAAA/wAAAP8AAAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8A
AAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP9h
9gMAAIpUAQAABgbgAAAH4AAAEeAAABzgAAAp4AAANOAAAEngAABaAAAAAAAAAAAAAAAAUQAA
AAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlm
AQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtkelICABYkARckAUlmAQAAAABUAQAF
1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCOABpILAAAA
AAAAAAAAAAAAAAAAAAAGKQUAAAAAAAAAAAAAAAAAAAAAAAYMBgAAAAAAAAAAAAAAAAAAAAAA
BpQEAAAAAAAAAAAAAAAAAAAAAAAG5gcAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAA
AP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAA
AP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAGSeAAAErgAABe4AAAWgAAAAAA
AAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAMkAROkAAAUpAAAFiQBSWYBAAAAYSQB
pQAAa2RYUwIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeU
tf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAQBAAAAAAAAAAYpBQAAAAAAAAAABAEA
AAAAAAAABgwGAAAAAAAAAAAEAQAAAAAAAAAGlAQAAAAAAAAAAAQBAAAAAAAAAAbmBwAAAAAA
AAAABAEAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAA
AAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA
/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYD
AACKVAEAAAJe4AAAX+AAAHDgAAB74AAAieAAAJDgAACa4AAApgAAAAAAAAAAAAAAAJ0AAAAA
AAAAAAAAAACUAAAAAAAAAAAAAAAAlAAAAAAAAAAAAAAAAJQAAAAAAAAAAAAAAACUAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkW
ABYkAUlmAQAAAGdkUG4pAFkAAGtkRFQCABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQB
AAAEAQAAAAAAAAAAAAAHlLX+CNYaAAH7/zwjgAZBIwQBAAAAAAAABAEAAAAAAAAT1jAAAAD/
BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWBAAA
AP8b1gQAAAD/HNYEAAAA/x3WBAAAAP9h9gMAAIpUAQAABprgAACb4AAArOAAALfgAADF4AAA
zeAAAOrgAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAA
AAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUA
AGtk2FQCABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+
CNZyAAX7/40LthDCFlYbPCOABpILBAEAAAAAAAAAAAAAAAAAAAAGKQUEAQAAAAAAAAAAAAAA
AAAAAAYMBgQBAAAAAAAAAAAAAAAAAAAABpQEBAEAAAAAAAAAAAAAAAAAAAAG5gcEAQAAAAAA
AAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAA
AP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8A
AAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAA
ilQBAAAG6uAAAOvgAAAH4QAAWgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0A
AAMkAROkAAAUpAAAFiQBSWYBAAAAYSQBpQAAa2TEVQIAFiQBFyQBSWYBAAAAAFQBAAXWGAQB
AAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAA
AAQBAAAAAAAAAAYpBQAAAAAAAAAABAEAAAAAAAAABgwGAAAAAAAAAAAEAQAAAAAAAAAGlAQA
AAAAAAAAAAQBAAAAAAAAAAbmBwAAAAAAAAAABAEAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAA
AAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAA
AP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3W
FAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAAIH4QAACOEAABnhAAAj4QAAK+EAADTh
AABF4QAApgAAAAAAAAAAAAAAAJ0AAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAlAAAAAAAAAAA
AAAAAJQAAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAFkAAGtksFYCABYkARck
AUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNYaAAH7/zwjgAZB
IwQBAAAAAAAABAEAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAA
AP8AAAAAAAAA/wAAAAAU9gEAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP9h9gMAAIpU
AQAABkXhAABG4QAAVuEAAF/hAABn4QAAcOEAAHLhAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAA
AAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdk
WS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtkRFcCABYkARckAUlmAQAAAABUAQAF1hgEAQAA
BAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCOABpILBAEAAAAAAAAA
AAAAAAAAAAAGKQUEAQAAAAAAAAAAAAAAAAAAAAYMBgQBAAAAAAAAAAAAAAAAAAAABpQEBAEA
AAAAAAAAAAAAAAAAAAAG5gcEAQAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAA
AP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/
AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQA
AAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAGcuEAAHPhAACA4QAAWgAAAAAAAAAAAAAA
AE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAMkAROkAAAUpAAAFiQBSWYBAAAAYSQBpQAAa2Qw
WAIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIA
Bfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAQBAAAAAAAAAAYpBQAAAAAAAAAABAEAAAAAAAAA
BgwGAAAAAAAAAAAEAQAAAAAAAAAGlAQAAAAAAAAAAAQBAAAAAAAAAAbmBwAAAAAAAAAABAEA
AAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAA
AAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c
1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEA
AAKA4QAAgeEAAJDhAACX4QAAouEAAK3hAACv4QAApgAAAAAAAAAAAAAAAJ0AAAAAAAAAAAAA
AACUAAAAAAAAAAAAAAAAlAAAAAAAAAAAAAAAAJQAAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlm
AQAAAGdkUG4pAFkAAGtkHFkCABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAA
AAAAAAAAAAAHlLX+CNYaAAH7/zwjgAZBIwQBAAAAAAAABAEAAAAAAAAT1jAAAAD/BAEAAAAA
AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWBAAAAP8b1gQA
AAD/HNYEAAAA/x3WBAAAAP9h9gMAAIpUAQAABq/hAACw4QAAv+EAAMbhAADR4QAA2uEAANzh
AABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAABIAAAAAAAAAAAAAAAA
SAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAKUAAGtksFkC
ABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7
/40LthDCFlYbPCOABpILBAEAAAAAAAAAAAAAAAAAAAAGKQUEAQAAAAAAAAAAAAAAAAAAAAYM
BgQBAAAAAAAAAAAAAAAAAAAABpQEBAEAAAAAAAAAAAAAAAAAAAAG5gcEAQAAAAAAAAAAAAAA
AAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAA
FPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYU
AAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAG
3OEAAN3hAADq4QAAWgAAAAAAAAAAAAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0AAAMkAROk
AAAUpAAAFiQBSWYBAAAAYSQBpQAAa2ScWgIAFiQBFyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAA
BAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2EMIWVhs8I4AGkgsAAAAAAAAAAAQBAAAA
AAAAAAYpBQAAAAAAAAAABAEAAAAAAAAABgwGAAAAAAAAAAAEAQAAAAAAAAAGlAQAAAAAAAAA
AAQBAAAAAAAAAAbmBwAAAAAAAAAABAEAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQB
AAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/
G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8A
AAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAALq4QAA6+EAAPrhAAAF4gAAEeIAABziAAAe4gAA
pgAAAAAAAAAAAAAAAJ0AAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAlAAAAAAAAAAAAAAAAJQA
AAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkA
ABYkAUlmAQAAAGdkWS85AAkWABYkAUlmAQAAAGdkUG4pAFkAAGtkiFsCABYkARckAUlmAQAA
AABUAQAF1hgEAQAABAEAAAQBAAAEAQAAAAAAAAAAAAAHlLX+CNYaAAH7/zwjgAZBIwQBAAAA
AAAABAEAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAA
AAAA/wAAAAAU9gEAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP9h9gMAAIpUAQAABh7i
AAAf4gAALuIAADbiAABB4gAASuIAAFHiAABaAAAAAAAAAAAAAAAAUQAAAAAAAAAAAAAAAEgA
AAAAAAAAAAAAAABIAAAAAAAAAAAAAAAASAAAAAAAAAAAAAAAAEgAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAABYkAUlmAQAAAGdkWS85AAkW
ABYkAUlmAQAAAGdkUG4pAKUAAGtkHFwCABYkARckAUlmAQAAAABUAQAF1hgEAQAABAEAAAQB
AAAEAQAAAAAAAAAAAAAHlLX+CNZyAAX7/40LthDCFlYbPCOABpILBAEAAAAAAAAAAAAAAAAA
AAAGKQUEAQAAAAAAAAAAAAAAAAAAAAYMBgQBAAAAAAAAAAAAAAAAAAAABpQEBAEAAAAAAAAA
AAAAAAAAAAAG5gcEAQAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAA
AAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvW
FAAAAP8AAAD/AAAA/wAAAP8AAAD/HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA
/wAAAP8AAAD/AAAA/2H2AwAAilQBAAAGUeIAAFLiAABT4gAAVOIAAF3iAABe4gAAX+IAAGri
AABaAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAAAFAAAAAAAAAAAAAAAABEAAAAAAAAAAAAAAAA
QgAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAABEAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAEPAAAL
DwAYhPz/GYQBABsmYCMkAmdkymBzAAAEAABnZAQNoQAABAAAZ2RZLzkApQAAa2QIXQIAFiQB
FyQBSWYBAAAAAFQBAAXWGAQBAAAEAQAABAEAAAQBAAAAAAAAAAAAAAeUtf4I1nIABfv/jQu2
EMIWVhs8I4AGkgsAAAAAAAAAAAAAAAAAAAAAAAYpBQAAAAAAAAAAAAAAAAAAAAAABgwGAAAA
AAAAAAAAAAAAAAAAAAAGlAQAAAAAAAAAAAAAAAAAAAAAAAbmBwAAAAAAAAAAAAAAAAAAAAAT
1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEA
ABrWFAAAAP8AAAD/AAAA/wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/
AAAA/wAAAP8AAAD/AAAA/x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/YfYDAACKVAEAAAdV4gAA
W+IAAFziAABd4gAAX+IAAGDiAABm4gAAZ+IAAGjiAABp4gAAauIAAGviAABt4gAAceIAAHLi
AAB44gAAeeIAAHviAAB84gAAfuIAAIDiAACB4gAAguIAAIPiAACE4gAA+vD67PD68OHw+uzb
7NHb0cbR2+zC7L66AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmgEDaEAAAYW
aJhEdQAABhZofApbAAAVFmjveuQAQ0oUAG1IAARuSAAEdQgBEwNqAAAAABZopUd5AENKFABV
CAEKFmilR3kAQ0oUAAAVFmh8ClsAMEoQAG1IAARuSAAEdQgBBhZopUd5AAATA2oAAAAAFmil
R3kAMEoQAFUIAQoWaKVHeQAwShAAGGriAABt4gAAbuIAAG/iAABw4gAAfuIAAH/iAACA4gAA
geIAAILiAACD4gAAhOIAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2QEDaEAAAEAAAAFAAATpAAAFKQAAAALMAAJMAAm
UAkAMZBoATpwxQ0gADswAh+wgS4gsMVBIbCgBSKwoAUjkKAFJJB4BiWwAAAqAAkwADGQaAE7
MAIfsIEuILDFQSGwoAUisKAFI5CNASSQAgQlsAAAGLBrAQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABuHQIARABkANgTIAsAAAoAAAAAAAAAAAAAAAAAQAtPBugD
6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPAwAAAAsgQK8AgAAAABBAAA
AAoAACMAC/AMAAAABEEBAAAA/wEAAAgAAAAQ8AQAAAAAAACAYgAH8OocAgAGBlqobaUIseQ5
cMJq0/GMzdT/AMYcAgABAAAARAAAAAAAagMAbh7wvhwCAFqobaUIseQ5cMJq0/GMzdT/iVBO
Rw0KGgoAAAANSUhEUgAABegAAANQCAMAAABkUX+NAAAAAXNSR0IArs4c6QAAAwBQTFRF09PT
y8vLKUNbcZy8UFBQ+vr6aZS0HDNKU3ubxsbGpcnez8/Pubm5ZZKzLCwseaTFLEhhp6eng6vK
YI2ueHh4MExlNlJqCwwNmZmZXIemwMDAiIiIFStBbZq7daHCirTUWIKiZGRlIDlQXompR2J7
YIurHzdNSWuIlbzZQVx0TXOSJD5WPFdwboSXFig6kaW2ZY+uy9rlfarKV4Gfqr3MaZGwT3WV
ZHyTGS9GVnGKeaG/wdPfirDNcZm4MUdcaI+tl7bMUWuEUXiYYo+wipmnb5a02OPrc5+/YYek
d5++YYmnape4Vn2dS2+OZY2rvs3Y5u7zXHmTXYWjIjxUWoWlcpOseqfIsbKzY4upW4Kgaoqk
JDpR6/H2JDxSGRsdra6w1NneJz5U8vb5JT9YeJu1j5CRc42h9vn74unvwMjQYo2tXomngI2Z
4ubrka7EhK/Q0Nbbb29ww8fKWXWPYGt1REREZoagPDw8f6jGbpi4YIut8vX3VoGh6u3u4uXm
6Ovu4ePmHjZOz9PW8PP22tve6enp6+vr5+fn5eXl7+/v7e3t4+Pj29vb2dnZ19fX2N3h8fHx
8/Pz39/fycvOu8PL3d3d4eHh1dXV9fX19/f3LT9OWoWjIjxSIjpSHjhP4ePh3d/d5efn6+vp
4+Xj6evp6+nr6efp4+Hj5ePj7+3v3d3gXoen7evt5+Xn7+3t2dvZ393f5eXn5+Xl2dfX29nb
3+Hg29nZ9ff44d/f5efl5ePl3dvb2dfZWoOj19nY3+Hk5+nn6+3r6+np7e/t8/Hz09XTy83L
7evr6Onr5eXj5+fl7e3r293b7+/t3dvd8/Xz8/Hx4d/h4+Hh39/d1tXX9ff1ycnJztHS8e/x
x8nJ6enn7O3w7e/xVn6f7/Hz8fPx4ePj4+Ph1dPV29/i393d19fVycfJ9vX38e/vw8PDxcPF
6evr8fHv6efn0c/P3d3bXIOjzc3N1dPT2Nnc9fPz9fP1z8/R0dHRys3P7/Hw1dfV1dfZAAAA
////zMzM////8wn/SQAAAAlwSFlzAAB0RAAAdE8BQpI5oAAA/KlJREFUeF7s/V1wlWeW5wsK
9OHEAgmwYAtIsMVXmgJjGaNKp2yBM20lKXDhLqAMLhqRNKarkszBSWXRiD41p8fZI2lLe0sp
VNYW2CYvztVEEHEuzgnNmRvUtzMXJ+LEjIKKnmnPTUUcgo6YCjPTcVSKNor5r7We53mf5/3W
99bmfcg06Fv73Vu/vfRf//VfVc+zk12B7ApkVyC7AhV9Baoq+tZlNy67AtkVyK5AdgWeZ6DP
HgTZFciuQHYFKvwKZKCv8Ds4u3nZFciuQHYFMtBnj4HsCmRXILsCFX4FMtBX+B2c3bzsCmRX
ILsCGeizx0B2BbIrkF2BCr8CGegr/A7Obl52BbIrkF2BDPTZYyC7AtkVyK5AhV+BDPQVfgdn
Ny+7AtkVyK5ABvrsMZBdgewKZFegwq9ABvoKv4Ozm5ddgewKZFcgA332GMiuQHYFsitQ4Vcg
A32F38HZzcuuQHYFsiuQgT57DGRXILsC2RWo8CuQgb7C7+Ds5mVXILsC2RXIQJ89BrIrkF2B
7ApU+BXIQF/hd3B287IrkF2B7ApkoM8eA9kVyK5AdgUq/ApkoK/wOzi7edkVyK5AdgUy0GeP
gewKZFcguwIVfgUy0Ff4HZzdvOwKZFcguwIZ6LPHQHYFsiuQXYEKvwIZ6Cv8Ds5uXnYFsiuQ
XYEM9NljILsC2RXIrkCFX4EM9BV+B2c3L7sC2RXIrkAG+uwxkF2B7ApkV6DCr0AG+gq/g7Ob
l12B7ApkVyADffYYyK5AdgWyK1DhVyADfYXfwdnNy65AdgWyK5CBPnsMZFcguwLZFajwK5CB
vsLv4OzmZVcguwLZFchAnz0GsiuQXYHsClT4FchAX+F3cHbzsiuQXYHsCmSgzx4D2RXIrkB2
BSr8CmSgr/A7OLt52RXIrkB2BTLQZ4+B7ApkVyC7AhV+BTLQV/gdnN287ApkVyC7Ahnos8dA
dgWyK5BdgQq/AhnoK/wOzm5edgWyK5BdgQz02WMguwLZFciuQIVfgQz0FX4HZzcvuwLZFciu
QAb67DGQXYHsCmRXoMKvQAb6Cr+Ds5uXXYHsCmRXIAN99hjIrkB2BbIrUOFXIAN9hd/B2c3L
rkB2BbIrkIE+ewxkVyC7AtkVqPArkIG+wu/g7OZlVyC7AtkVyECfPQayK5BdgewKVPgVyEBf
4XdwdvOyK5BdgewKZKDPHgPZFciuQHYFKvwKZKCv8Ds4u3nZFciuQHYFMtBnj4HsCmRXILsC
FX4FMtBX+B2c3bzsCmRXILsCGeizx0B2BbIrkF2BCr8CGegr/A7Obl52BbIrkF2BDPTZYyC7
AtkVyK5AhV+BDPQVfgdnNy+7AtkVyK5ABvrsMZBdgewKZFegwq9ABvoKv4Ozm5ddgewKZFcg
A332GMiuQHYFsitQ4VcgA32F38HZzcuuQHYFsiuQgT57DGRXILsC2RWo8CuQgb7C7+Ds5mVX
ILsC2RXIQJ89BrIrkF2B7ApU+BXIQF/hd3B287IrkF2B7ApkoM8eA9kVyK5AdgUq/ApkoK/w
Ozi7ed4VqH0y0lsqVj1eVz81lu8duHu/Nrs62RV4Ma5ABvoX435+IW/lQHH7ph0tNbe7c7nv
I08u19BQ09LUfH5NIeP+C/kweSFudAb6F+JufqFu5N3pTTdvdcewPYb6DTU3N80OvFCXK7ux
L8IVyED/ItzLL8htzJ/fUdMwL8D70Z/rrtmxfeQFuWzZzXwBrkAG+hfgTq78m3j/8Y5b3dGF
+nzf0n1rx/qZyr962S2s/CuQgb7y7+PKvoX9l1viqvhcd0PDrZamph3XmjedX7+ufjTPp1Cc
Xrf9/OVNzTtu1ty63RCr4ne3XM5oX9kPosq/dRnoK/8+rthbWLu9pSG8WM813G7Z0fx0olAo
lEYL+UIBaMcRyNunv7+/tzdfwF/9/WOXm1qiGre5hqbHWa+2Yh9JlX/DMtBX/n1ckbfw3vma
EK0G9XtN0+VioVQqTZQI7c4J5TwzXp98b19vf377tZsAfvApJHerOevTVuSjqfJvVAb6yr+P
K+4W9jbfCmA4132raf3o6P8FJbw68+B8rz79vf9db//lMO9OrmbTk4q7oNkNqvgrkIG+4u/i
yrqBtedr/JDPNdRcqxodnVAnivPhwo1T0BvQW/84f/O2/wt216zPZJzKelhV/K3JQF/xd3EF
3cDeHT5NPtdw8/zo6GiphP8sHPRhnKfX/Xe9mwLNgO6bYxV0YbObUulXIAN9pd/DFXP7tvtK
+dztpvrRsTEgXo5b0AcV+uSKPgr0eH1/b1/R7+DM1TyumIub3ZAKvwIZ6Cv8Dq6Mm3e/2S3l
u29dKxrCpwR9cis2GvR96gS6A7fOZyJOZTzEKvxWZKCv8Du4Am7e/U0O5eF9GbMKeV9BPzF/
iT6Z88D94GChyRXtGzbdr4CLnN2Eyr4CGegr+/5d9beu9rJD+e6Wx6B8COeXUKLv7dUFvfw9
ONg3fdP5rhour/rrnN2Ayr4CGegr+/5d5bdu/W3LzZ67fa34/2DMx4A+0lwZlOgdww1PTkUd
F/QC+95mp7CvqV/llzr79iv6CmSgr+i7d1XfuPpbFuW7a7YX6cwb9IkS/dw4j7K+r++y7efP
tfSu6sudffOVfAUy0FfyvbuKb9v9HZZ7PVezfWzM5rzntYmQ6OcxFjtX0A/iDAw8tr1A3dey
YapV/Jir5G89A30l37ur9rZNW8V8rma9orxX0CeCPjAWuxBzZZhyQ5gn0A/MjEzbrL81vmov
evaNV/AVyEBfwXfuKr1ptVYxn7t1nit5fZRysxigTy3Rx3IeqMc5b/USupszx+UqfeRV8Led
gb6C79xVedOqrGL+9iaH8guR6BN7sfNTboTzdK5ZPpxMrV+VD71K/qYz0FfyvbvqblvtJi+S
svvmpB/z5dSLFeHGPvmb3jffsH7VXfvsG67kK5CBvpLv3VV222zN5vb5oSDmVwT0KZQbg/t1
noST25EpOKvs8VfJ324G+kq+d1fVbbvXYtyUocW8Za4sN4negH5mpu+m5xa6mY3MrqpHYCV/
sxnoK/neXUW3rb/GYB7FfGg1v7imG18vdh4SvU+5oRdncEasxIaWbAfhKnoMVvK3moG+ku/d
VXPbqkwnM9cyHIl5o9xEVvTzXzoyB9CLszIg0SvOE+uLnuGyJpuiWjWPwkr+RjPQV/K9u0pu
2xrTxMw1FYdwwtT5lZqLnYtET5Dnon5kxrOI3i6ukrsh+zYr+ApkoK/gO3d13DSvmu9uLjLn
VzvoRwD6kZFm8/TVMLo67onsu6zcK5CBvnLv21Vxy0pGtGm4/D8y5ecD+rlvl1r4uFRQovcK
eqAexwvevN23Ku6M7Jus2CuQgb5i79rVcMN6jR3x9vbJyckk0C/dXOyiSvSCeTrbzdNYzchq
uD+y77FSr0AG+kq9Z1fB7RowTptb9cB8WYJ+DhI95JrgqTdPZS1Z4NkqeExW6reYgb5S79my
v133DeZvP2bMG9An9WKX03QTCXpLuSHJxvLc+Gg/ZFDflI1Qlf2jslK/wQz0lXrPlvvtatK+
+YanCvOrCPQhFnox0YvnxndmtYCTu1bu90r2/VXoFchAX6F3bJnfrO16frRh/ZDhvNbokyp6
/1rwUb1HcAls9FZFr9zzSS76MAHHaPW5Z2V+x2TfXmVegQz0lXm/lvet6tUlbsPl8eHhlQB9
2rnYuUj0UQX9yN27d0cua7Pl7YHyvm+y764ir0AG+oq8W8v6Rt3XoTbdm4D5JQB9iq0jiaBn
wvvXgsu22ISx2GBFD9DfvftfmvUvMU1lfe9k31xFXoEM9BV5t5bzjdLAy+2YIsxboE9yV0Yu
jF2wjX5Oa8HnB/q7d5/sUG2JXJZhXM4P0Ir83jLQV+TdWr43qkpLGDVVfs4n2uiXAvTRBnp+
S0C6SQy6iSjouao3ftKGfPneQ9l3VolXIAN9Jd6rZXubarWlsmH7lOJ8UKKPTECY97xU3nf8
Y7H96Sv6SNBHem5IojenXncnWjKrZdk+SivxG8tAX4n3arnepvVau2iewhHhZhFBn2i6YcAz
9BM1ekH/YvViLdQb5aq+XO+l7PuqwCuQgb4C79QyvUlP9OTQzfHhONAnuSvnMi/lr+XVyyk5
Hw36yKCbOOVG4V73omuyor5MH6kV+G1loK/AO7U8b9JlVc7fnh0nzEdX9AsGfd5vuwngfgVB
f+/evQml3+S2l+c9lX1XlXcFMtBX3n1alrdoRMNtU5Vgfv6gj5iXKpWY79BvAvbKxQP9AiV6
1PQA/b37m5TV8ta9sryzsm+q4q5ABvqKu0vL8gY1q3K+pqpK1fOLA/oSOyvlvxNKo18MG73q
zqY33UT2Yu1WLP2bQH/v3t1b6oJcLsu7K/umKu0KZKCvtHu0HG/PoC7nL4/juAX9PAZjJ/w1
vfLRryLQ33uyXhX1DVmoZTk+ZCvte8pAX2n3aBnenk2qem0ZJs7PE/Sjo9KEHYvsxS5jRT//
XqwU9KzfaKtpptSX4WO20r6lDPSVdo+W3e2pVSpF9/nxqrmCfmyMOrPyX7MaPKDRJw3GBq03
KZuxaTKKFfPjgm5s9cYD/ZP769TwWE3Z3WfZN1RpVyADfaXdo+V2e6aURNHCkJ9/RV95oH9y
T6f+5Erldq9l30+FXYEM9BV2h5bbzVGx893bx6fiQa9MlUuxMTapok8/FxsZaZa2F+sV9Pee
4NyfVUX9jnK737Lvp7KuQAb6yro/y+zWDKguLJltwir6IYTRU5TZ0i4SXEl3pc90Yyk3BPon
9+4qpb7hbpndddm3U1FXIAN9Rd2dZXZjVORBrnlYyfMM+8lJiT5Y9gQEA/yUEv0cIs3mXtEz
56mo1576LNKyzB69FfXtZKCvqLuzvG6MLlZnx6soqpJtlQHXTWDtyLwzzRKjbpYe9IkBCP6K
/sn9+0/0GpaW8rr3su+mkq5ABvpKujfL6rYMKPm5aRycj5BuljfTbNFAvxjuSl3Q38fRjYz7
ZXUHZt9MBV2BDPQVdGeW1U1ZI+b53HqifAZ60eoDBT0qejpr5EkxN1xWd2H2zVTOFchAXzn3
ZVndErVNqaaKy/kXFvQJvVhI9HLuKZmruazuxOybqZgrkIG+Yu7KcrohtSqR+JqivA36hWaa
zSWlWGJvFt11E5BuFtCLVaSvvSa/Ad3KsovL6YFcMd9LBvqKuSvL6Ib0yZBUbrvHec9euVDQ
R4RXmkyzxQuvTD8YO2/QK8yzfCMXrbuvjO7I7FuplCuQgb5S7skyuh1PpThtsDBvNWOXGvSL
F165vKC/r5Ocs+ybMnosV8q3koG+Uu7J8rkdykOCzAOb9P55qchNgkl7R5Iq+lUL+vu1N+UZ
MhuTLZ8Hc6V8JxnoK+WeLJfboeX5Zqeer4yKfu5rR5KasZZ0Q/9UW7iylLNyeTRXzPeRgb5i
7sryuCFPlFFw+/QLCPr081JmLtZH+lG5fA1ZS7Y8Hs4V811koK+Yu3Llb0jtk+eqDXvbj/lg
1M1qlG6SKvok0EfZ6G3ai1+pe+T5vQz2K/+QrpjvIAN9xdyVK3hDnuTXXG6qyX1fo8JtWv7p
n3z1fAb6uHkpC/S1tS0i1K+v+T5X03R5Np9toFrBR3bFfOkM9BVzV67EDRkZfdp887ZKnEcd
qpqJfsqHzUtlFT1HmvlPba121Jurmrt9c9PT0ZGVuH+zr1kpVyADfaXck8t6O2oHp9Zfa1EZ
xEJ372wK4fxSVvQLXTCVPo5+GaQbgL5W/V7kv64NLdfWFwcyQWdZH+mV8sUy0FfKPblMt2Og
6vyOGlW5+0nEL5twGxf3gTj6xavoKw70tcOmmg+5xN01O85XDSzT3Z19mQq5AhnoK+SOXPKb
Uds7u+lmRA1v4aj7caAPGx51k4E+SrpBTT8Y91QqV7vh5qbZ3qy8X/LHfYV8gQz0FXJHLuHN
uF942tySTB7BT32YbrO0Gn3lVfRAvQoLCv2lyX5ebWl+WsjatUv46K+QT52BvkLuyCW5GXfH
1l+DmSb9ieR8ptGndt2QSo+T/MuTd7fkaqDeZ7sIl+RnoEI+aQb6CrkjF/lmzAxf3nFrLogX
6tSE6zZZRR8fR+/YK4Xzz1Vucfon2e9zt5ouZ+L9Iv8gVMqny0BfKffkYt2O2vz2uVXxHopa
Ls9moHeHptwIhBQDU6qex19FZaifA+q5GX7r2vZSpt0v1o9DpXyeDPSVck8uwu0YGU/TbnXB
093Q0qSWjFyrn55eCOiLxSE6ZRxqtkz2Sg37ZrnUO5paGlK2SMx9g1ZtVea8X4SfiUr5FBno
K+WeXNDtqO1/OtcyvvtWy45Nj3//q8sf/lTw0gzMzx30k8UiNonofir9XaL/l+i/dEbH6O34
L/4a47OC6ZXLDPraTXJlf3fj6O9/+R837Wi5NTfeQ7p/2p8V9wv6yaiUD85AXyn35Hxvx93h
y01zafx9311z89r5f/jl39z48Md7D+FcsTmfvqIfLo6V+nGccaW8vIQgeOfV9H5YE1UolCbw
pBAgvXpOwLMDnSWMKV5u0OvRqa1/ivNv/uLG0Xf/8L+dv3Yzdo4hoPQ0NF0ezhq18/3xqJSP
y0BfKffkPG5H77rmuXhqcg01TZvW/f7LN4nwWw/R//D/s0IWjMPGVvSw3Uyheh+dKBRQnpNA
MzY2Ucgz5/WCj8FB+pemqe9veSd6d0AfyCfmq7NqQO8tB49Kr7zvafT8r3VydQ8R6eV8+hdv
Hv34l3+zqammYQ7N8lzLtTWD83iIZB9SIVcgA32F3JFzvBkj9XNhfK6hZcflL6HS/PkBoN3+
c+iSkOgy6fPh0s341PAQdJcSqN7fC0T3G7D7Njj5yB5YzKpf0cefgIjPRb4Rfla+op8JxFfO
MY/+vh/0tdNCc4v0ivef3fjyrb+/vKPFSxoK1PL+V+Rqmusz4X6OPykV8u4Z6Cvkjkx/M+5O
bWpJXQt230bAyj+/e/7D3x3YCsB7jFcl/UGGSe7ydATox6HQjGI9tyfRBPfzeQW9g/pI0Bvg
490J+FLhm52xSyjd6N82Fm85eCDULED6MbmvDng1Pf3rZz/46NMzJ09/duPl3/78l4gdSq/e
51o2DWcTVul/XCrkPTPQV8gdmepm3B+7fDNtP6/71s3m7b/9+/c//PGP9h5AIU+Y5//jv6ao
XyucP19fHwL6KWK8hfhAJe+JNuB1f2/aij74DEC8l/J+aTX6lQB9bSjpf/bRR9/94sLxzp6e
G5s7Oj+7cfS3f0COaGrxvvvm+dGsS5vqZ6ZC3ikDfYXckUk3oza/Pm3PNYcqfvsf/vkoN1sP
HDiwl0FPqOf/e5jfulE4vx6cd0APNZ4FeLvT6q/kDfbpvfiNAnoj0kOhAdJJosGrBgYG9T88
zs/wGRjg/wzgQ0nNCRb0BfRx3UPNXetExVcu83Jwqe59Ij1enJSafq9d0//so7fPAPQdmzff
6Ok8/elHP/vZn36EZu1v/8PTa6nFnIam9fmM9kk/OBXy9gz0FXJHxt2M3qc70kanoN36N39/
9MM3frTXO/j3AaY7CzeWfLPF4ryAHqthIci7dbzCaKhkA9nFen1/Hh3Wgq7sE6UbArzvAPdM
exf38wV9sJmgfulYPOkmNJDez/r6AOl/9jNWbo5Xb37vRk/bhU9/8DMcCDp4/V/c+PLd/4hW
bcrf3G7veNr7AvwIvPA3MQN9ZT8Eaoub0hlr0G+9tv5XRz/8871UxKOMRyGvjoBeSnnDe/xD
OP/9+X+igp6HpcaHjJMmUCVHVvR4A3knYcBxtRuiKQQdOfqXA+PHxBv8oB8Z0SU+aG+X9ksP
ev2tzLkZmwr0tbNypX/0J7qoJ4n+FxdOt32Giv6T4ye/Jc7rY3BPGwNSNWNyNZvGstK+skGQ
gb5y79+R2WupCvnuW02bHn98+V//lAV4rthxGPQ/Un/wT8a/xftDWwQimxjz9dNxkLc9lD7g
E5FVVa+km352y48WSLiRAp3oLlZ6fkbQ9XpeoX5QYdaiLKQcgj0+N9X2Kwj6kTlnIIRoN7W1
jxXpDeg/+hYS/em6z957773201LQB84P/vLG0bf+flNTukbt7WuzmSOncmGQgb4y79v+9U1p
fneHbXL9//FXb/7rvYrxqtcqPBd9HqjXwEexb+r6Q1uF881V9fVV45MBST6xohfx3TqEfEzC
jpL/kpifLN3oOpq9N319A249TcK96DjlA3rPSH9POemTbTcs5GwXlezPhPSi3Fw4Xtf13o0b
1RfeDgc9kf8HP/jLN4++NbZ+R9Q6MHkGUae7aXtfZf48vPC3KgN9xT0Eascup1FrGmp2bP/H
L998w2G8zXup7B2pnkScLWv3Hz78zqFDwvlrVVWTRX/f1UC+v8D/zNNfZIyJsFb2F0bJZi98
N8e1zVM/NlIaV01ZNtc7vB9g2PNYrX1SNmMjNfrg96J6BQHpxlfRzxv0akY2J+KNUm6Od7a/
996N6pPf/uBnpNeEnx/8DH/+zWdH3/0PiJxO8eSfq7mcGXIqDgrPM9BX1H16tz6NWtNd07T+
H75888ewxiccAj3RHaLNliv7D3fntOar6vkdQ2NkrnFzDFBFM+DzEmigYg3UnFRv3qM9V9vG
dGMwzwI75qCQbzNKSC0h5EbNwNLfCMLBfynpoIQ/eH7QDVmhLKs94L1m7uCgwH5ZQD/3iamg
SB+q3dTWnucn1m4m/c9+8DZL9J3tN967cecXH8VwHkU9/fkB/v/dZ0ff+seERZCqtL/VXJ+l
JlQUGTLQV8zd2bc9hVqDzPJNT2GcPLR1i8t434tKrEdVf+yrdwB45zd8EhH4FU2FCRfyxSJB
ljGv4G+eA3iaNXIqlkddoc6PIsKSU85oyIr9leZI/I1k3hDlKfaG1fw8SN9L721jln2ZCvYz
fYC9TFbJWbKKfglBrxLODjPoRblp62y88V5P5xkoN9EVvYCeUP+Djz46c7rrxsd/+P3lphS7
BhqanmahCRVDhwz0FXFXzjxNhnzu9k1i/O/AcFDdA/sW/DuI+Y0PXjrcHQS8A/ybnhumUAJX
J4qEdVXB+0V6r5DvL1hVPY86Ed85JIFwHZkcFirdUP1OJf1gYYLKe3pyCOoneM2Mo+Kk89GH
ZDUsnr8yWqSPKOlrJQ36Imp6Aj0K+o6O9hub29vQi43hvAY9o/4Hn548Xd1z48b7L//2nzfd
TE5P6G56OlMRPyAv/I3IQL/qHwIja5Ih39DSvObjy28cYKYL5pntQcRvuQLAG4XGX8g7L7eY
ar04PAGuj0UgXpCvQsmcmp4MMXpcKhBnRoILVe/gu8pQGBzwieM+Fz3en+WcKNzPAPek2Pen
LenTT0xF+isTRfrU2k3tfdlEcgzKzbes3HR0YC6WQP+nKSp6VdWfvPDZ5jd7ej6ra+t6/+Of
1zcnN2m7dzzOZJxVT4kM9Kv6LnxSvyMpYjh3a8f6f/ySCnmBPDNe015gz2fjVSJ8NNlzCKBv
2rS+eFO/yy3i/CgV8cUh0mtiMS/RwxqclG3mVPXyBpptVdYbEujVyQ8M9NNLOowezhwU7+K8
x6cd9GgvGj0+B2s7pP4POtX9XXbaC+sXeTR2OUCvN4YfgkTPyg2Bvqfr9LfAfLJ0o0D/6Xdt
PW9uvrG5sbqro6OzY/PRt/56e/LSyIZrz7J8nFVNigz0q/buu1/VnAT57prmNb+FsWaLZrxh
vfBdqvq1Lx0+HF3DI5z45o5N6/rVdVK7MNAWBGWnpsfx3yKV8wmY96yU1KO1TZUcWzAB7YZQ
zmynOErKrFERCiTUD3J/FoeWjzh59LSbBO/dD4Kb/ivhXk1McbNXv4E87UR+Jdh7rPfLTObl
QEkfJd3MA/Rz125q78sdvvcHPBZb91lXz432jpOUfxBJeuj3SqQX0r/96fH2np6e997bDNZ3
dradPrntLzd/+Ydn11qSHDm3m6vur9oflhf+G89AvyofArVDzUmzUFgmB2fN77wK3oE8Y37t
H3/YHfnj3X27puna+ekB9/qoaXx0Y//PxHn0XvPcf00+xEyCrlfVU00PSkv1TW9ImWrGdT9R
n1z3fPDEgMIehTyN11pFvMZ9v7xOhpdGCPZuXT9n0Ef6KxO7sUGDZXrtprZ2hH/lyv0JKTfH
O6u7Nt/ouoBebGxF7xPp2+oI9DcA+p6ujjaA/szbH3300bef3Xi3KnmR5O3mYjZCuyqJkYF+
1d1ttaObbsVq59gP3XT+V5ffoP1PRq+xavotW9fu/mFkDU/rRZq3F8OLt0H9vJBb3987VjXW
21saTWa8aPQ24wnuQVd9COh5FQmV9KHjUzNIMmMvTalE1huu+UWit4FLfhvq0M44U6pgPZl4
+JQb6KPasbW1BSG9gL7rM4D+pEj0kdqNr6T/FKD/7LPqnvfef+/VzV2dbRd+/TWBns8vkIq2
PtGQU7Mp2z2+6qCR+ehX2V02sF46cpGnu+ba9qMf/mQr1BreAOUTbTDtFCXEC+HzcRek1jzD
bMr3F8bhtElUbHwqCNT5fNjclPZNwi8p0oyn0RdHAXm8kjdSsS3HQN/XjB1R+o5W6P3+m77+
Xhv2VNcL65cS9NHd2BjtJpr0z/ieP/yL0zBXYi52c8cv3mbMpxXpv6vrbO9obevoee/1998/
Ut124eGnb8N3KecHH3377Wfvf7w9cbKqZX3mvFxd5Mgq+tVzf9WOJ3ReG1o2/dPRD6HIy+G4
AgP6jRehxIc+P+RoC+z6NOOQphHbBOl7KmUpr96NlRsnq7JQwKuk4zo0id2C9Lf8JUdJ9mMM
enmFWg9OEn6Jme+gnnux9FRioord4v7uXQpHG7ALe+rdmuS04A1aUtuNBn2IdhMNejU4dYxA
3w7Qd56RXmzCaKz20n90prOjveP08eM9r77/+qubq++cfvjpt+Swt8+3//rGu79P0nEarg1n
Ks7qgUcG+lVyX/Wdjy/lAfn/35e/+amGPP5GRY8Yefy98dI7EVI8lovsOD+U+ufVNGJbSnC2
RNfBoc8A1kAs+qrooZacpqy4biJXTLFzkqp9Qr27HZzs89TgnfHkmpk+Md7I8dyWQDxke+j4
FuvpuSF9RR+5eiR1NzaVSB8WS6/Di8VOv/d4J+Zib/T8xdc0F5u2ov/ZR7/orG7sOE0lPUj/
fk9j58lPP/KDnqD/aTvGaDclmC9bzmeF/SrhRwb6VXBH1U7viLVEdLeg7/obU8kr2FOm8JV3
wrV4bAjccXn63txuu1p19P33t0fjle1wbnI3FrOvpQUtjeXxqlFvMbhqxuKJo3dmBGk6XisW
SDeoJzMmzDeqG0v+Sv0Ct2d5q0nYiazo59CNTdZuwkr6mJq+hknfvf/Qj+GupHGpWNLbGj2I
/ouOrp6OVurk9vR8/v57Pe11D0NB/6i1rbHjs/ff/a/N8Xac7mtVqQuFuT3csvdezCuQgX4x
r+ZSfK7e8/KDHXHgoATkf7rRKuX5n1GueNoQOL882lrt8+lWvsS0bVhPuwlys5fmWTnRgEpv
lOZWqLC2P/aGNWKpxEfzVbtuAHo4LAfRikUBbxlvBpB1bz5ln1fI874qI+LAiMORCSm0m8i5
XTdxx/bvRy4Ij9NuYkBf6z3rd3+1FYun5lDSf3Syq72ns/V0GxT+6s3vv9rTVXeGtPnAeXQc
oL9w8tNv/+L9d/+35vg0tJrzWeblUvzoL+bnzEC/mFdzsT9X7WxsKZ+rubbuyw9tuYYQvzGi
34oNgc3bF/CrdpN6qsmNg8BFeF3mptHbphsU5CTAQ7EvsUA/OTSE/9B/+Vg6Pf1zAqabsSL5
MPv9GZYwz7MPn6Qg+G5GlO/GZ7OENiMZN0AuBHlVYpNfx2N9BOqjjPQhLqC0AZaWdjNP0ve6
T/rd7xzb+yepurGo6C+0tzd2Hj/eVnfns+p2stN3tZ357ttQ0LdXXzj59rdvf/Tt24D931+L
jUTt3jGdFfaL/eO/mJ8vA/1iXs1F/Vy9l+NKeUD+aQDyEYzn7VGxdpoU3/g6TZdNxVEoMHFe
lfBnANnezTtFQsQbNeBE809eH1aIjxCEXt2eHeOpWHRU5Vi92AE0ZkfYXq9+R6B3s1yWoH1/
L0jPxh3F+hl6nRbsYcIJKjhz78YGnfTz1G5ianqR6Z1DtI9qyHoTUx+9DdD3EOg7O2kwliz1
XW3HHxqHpSH+p8fbAPq33/5WHcD+t3+zIxb2NZezpYQpfpBW5l0y0K/MdU/6qmPXYlR5SjXw
Qz6C8Uidvzyc9MXSvP2/6O/nZv9Ufz+L9OkrerK6hySERZbLoo/Ilqg8hd30ittSu25kSGoC
TxjuOsGRkUEapfI1Yj0ZhUSUQcmvtAR7iDhmlEoyjr2zFKAPaceGqvQxpI8YpOh+aUuQ9rZI
/+3bx6mibyPQYyy2rQ6o76qTmSn3fHq8jkEPw6UcIJ8q+/WxeQnd14ppHkzZ+yz7FchAv+yX
PPEL1tY3xWTONNxc//s3fwKFxqjy4YxH6PymRfx1Wnt+GnpJtplvM1ZxU9QWvAAbDVfoamQ2
2nVDAWfkutGBN9p4QwEIXOFzbS9IhyZjoZ5ns3rFUs88H+SdhPQ8pTT6EQrA1EK6T6xfim5s
Wu0mxnpzX+amnoZkkuUOf3XAV9qbiv4Hn37a1tPV3gnlBpyvazted6ezur29s+7CoyDoG3vs
il7T/tPPjv5h/c2Y7I1cU9adTfwRX/53yEC//Nc89ive2x5jo8zVNNcffePQxq0a86GMRx5x
8+M5OmqSroJ2VpJAX5gP6Nksw4NQk1PDrMKPAqJDk8PDw1DnSaAXFz0X65Jz0zfo5NHzClnO
rA8elPes0ZsDO73nppduLAR5LaLgreq5SgN+wJukclG/GCK9X7tJXdJH1/Qi09/G3XZvHXaA
B4Sci4f+xFs4ZYH+TFsPwI5W7B0C/emTF06e7mhvhLP+u0euUP9pa3sI6An3r507/v5b/zVW
sm/ZvsgPv6SHZ/b2pCuQgT7pCi3n2wfOx4QbNDSt/2d0XlHJM+ijGL9pKe7Skv4V47Eu59NJ
N1w8ixASvkcQ4KbObLEosA80Y+GZB+0xgOs4b8hK4482mygA9CUU7zbs9eyUWS9FKr3U9TrC
0h2gkjQcavFGeoWScs2SRfqwkj5cvIkm/Xpm+zX16LyLYVY/7btf2vojBXtD+k+/64QmXwfQ
g/Rtxy88PHPm0cnOdszKngmCvvGzC68ZjV4rOAD9mT3X2z55+a2/Xt8UU9jfOu9LSVrOn6Ps
awWuwFJQIbvM87oChU3RPzco5f/h/BtbgXf6s/FK2M4n7BWZWirng3ZWNptyPh3o4+Vut1om
wYVDLH1H5mJhuynl3QqfcG/5K6mi514sJrG80l5Gpwzo+8Fx7bLUrDcaPVP+Hv93hvfPkgdz
zgGWcwN9rPEGm8P1mFTgbzFB2T+/I0Ha5w5v2YuhWLNl6szDDoAe2nxnByT61pNnvv7utZN1
7e3tXW0P3Y4shVxWn/aasQb0b792Zl8rtpK//vLLL7/1y+aY9mzDpoUaAOb1c5R9UNgVyEBf
Fo+L2mJM8xWl/N8j2GAjH2QKB/f6gfFLKoxql0eNk+Se1IyVdi2ZbVhFkZxhPeqE+IM+yOtu
na+KZdJn8H4C/H7juaEtVGNk2bGqe3jneWaWB6bIR69sN2j+ekk3eBdzAHEYQ7XTxrDe+CxH
7gnpIfXL7tkl1m4M6CNK+mjSc1mQ8z9884HoAoj2e/9UavqPfnGyuqfrOBX0HazcnHnt2x98
e6atrquxq67tpN2ShXTT2HX6Neg5Xi0vTdlHDwH6js2vv/z66z2NPUf/sD2msO/esWS1R1n8
3K6ebyID/crfV7VrbkY2X1HK//4ySnk+V34YCCSj/YBLyni6PLPq2+v2bexIIj2/nRqfxPjR
ogSVkUQPMZ4iilmfp5gbbBEMzymG3xFUn9A1vnHd0DOE46/EGCxtjjWgV9EH3ugUJdrTgRbf
x4q9x3odayavuTcCZUWqekb93EE/z5J+rqS/y/dKTcjj924wgrL7qwME+oeftcM438kSPSk3
371NY7FnzsCL01l38jWrI0sVfSjoXzu350IrNpa8DtJjrnbPuV/0fPzL5pboR/DNNVmM/cpD
JgP9Ct8Hteuim68NTdt/pUt5TEH5Om7Uc11yxtPVqdWSUn3KxUwRTwB+ZE6gMQvWq2YstWOh
uwP5wa2xvXm8r99fSRvE+5FwY3vp5bcGy19Jhhyj48Bvw3xX+8GNOk91vXzP1JK9d2+Eynqi
PaF+UbSbmHZsYkkfWdM/5gfEpvAHcO06v+k9d/jYj052NW7+rK7OSPSfMui/O328urEdETiP
vJo+sqJ/DTtP2hCg8DrOe0eqr5977dNPX4PJ/mlT9IaElqcZ61eYMxnoV/IOqF0TTfnb1351
/sdovEKtQWCND/INN5sX0TqZcAm0cLMj7QY+crxAe4HUQtFlalFUmAoCITyP96OpWKsZy0gf
pThjuwM7iLatY6RX6QeQ7inQTA4EF05GcO2VlozDpTrX9uIQ1SkIelSKQS+ox2HUz72kd/YX
2jtPdCdYfRX+GveSSR+FegkTjZlSGvcH1XR/9ZP26rZOkeih3FCgGUj/6afw3vSA9J735tPT
7V1hFT2Um5On6wT0r77as6tt22s4YP2eGx//9lq0l6BlzVL1j1byB3j1fO0M9Ct2X9XWm9Rf
vzsuV7PpV2/+FMmTIWoNTUst67LmIfUsc9vP+RQTU4DzGGMchfv41KSabyVjpa8Ri/cj443f
djNGw1IW8KHHk5k+xF9Z4MRioWqf7axUCZYK9ozaASK98Yg6rEejlop5MH5GUE9ave9Ext2Y
6a0g6S3Eyz8V5BdGev4lryH+EVzwR1AePvY7GpciiZ6VGyI9JmbvdLRXHz+D18gR0H8a0OgB
+gutBPpXX3/1vfc+39X2kECPc+76nY6eo7/cFN2dvfksY/2K0SYD/cpc+trpyKGo7pbzv/rw
AFyU8Nb459zho1/2Hxb1G3lOIivtEy7R9JMNPvAm2OihvgyP0xkDOYtTU0NjE+6GcMxEoby3
w25Ioee4G9twg2cPX3olqTjAfL5g7DYUS28fGYfVI7B3Z+xuA34hUBxGXT8D0PdJPR9V1c8H
9AHtJtRiGSXTR7lv7vLj42biQ3jgvNswzTUc+JQlekTRK9CfpDwEGHJURxY1Pqw4rQR6txv7
2ncwV9bdOdGDev7zzzcf6bj+6BGD/ut96PBeP/cX7//yfGTeZTZMlXhXLdU7ZKBfqisb93mn
IinfcHP7l+i9hnhr0HVdEbdas3qyuaxrYA/1Uc3YfoVr4Dfor4SuA86PTeGQQD9cHCt51hti
KAyRuvuKOLMB47gcLdh2m37j35GgYnhuZmC+IcFH19POzJS23RgjvcN6L7UY9f094j2jHtTn
qn7ArekjnfRLV9JH+Cxljm1dmsdw7yaXv90XD3wkyg2fbx/Ce9PTjjwE6PYo6CNAD3PlHkj0
d7p6XoVw09jzSfupk1LTPzp5qvPO9TPnzlzvOvrW00gnTq5pKM13m73PIl+BDPSLfEGTP93k
jiiHwu0df7P+jS3HLvol+VxN0/ZlVWusG9GrvtmWQD2fFHZTQAE/NU40LwrwbVrmR/FGIT13
Y2G8IdxbGQi9EGnAebWCSos+o3Zp34ffAFRtXyLPDW0z4aWxXmFPIcWyfUQdMtJr2JuhKZbr
TUL9vXv0zQ5IVR+G+kUv6VPI9BFFPYviubS/5f3TtVvOY6/7q70e6c88PF7d09554VNSbt6O
Aj2bK+90nNgM0O/q6KpurG6Tiv7Rybq6jtZtjx49bL1zp+P9d+t3RDVnczsy1idjYpHfIwP9
Il/QhE83FpU7nLvV/A+Xf7fxG79c093SXL+836L71VSCZrcRtS3gh1T0o1Pj4Lql3k8Q0Kuq
xserxslGaWeb9ZfGihr00oxFC9bz3HCs2QDlGFuH90tNwFuvzwzpPQjEpN3gCvQMe89sw4n0
DuipPazEGk/CoRszyAoL+M63TFA/M/KEq3pLql980KcjfVhZH+mxjHjQ3PfNs+YuHlAlPYO+
h9IQgHoFeh6XtY30r50jib6jmir693Z1VBPoH3I/9rVtx9s62h4+eu3chbo7dW13Tvb86pfN
7vOKJ0R27yit5IP6BfzaGeiX8U4vRE1Fofn6+zd/etBvk79983L/Mn57YV/qvPrhfBZS0DvN
WO+FQnG4qmqqOGE9DeTHJlHcg/bj4xRlVkBdrg+GYY3pRjVjubpX+ZVU00O4N8dsjUXZ7hnp
B0i4maGpKWWk5zUmVmGvTPS0Z0rZK/HhwnqsHbQj2qgbS3hnC72g/i6L9bYBZz7aTaxK74E+
RqZHUR9E/STfQevn9DDxqTi5dw79jDqy3359uuMzRJkdP33mWwb98dN+0EO5gbkSEj1LNyfa
6qqrEZ9w/QyB/kxrhwY9SN9x+sK5RwhA2xTlsO++VpjTN52984KuQAb6BV2+OXzwTFTCQa7m
/D9/eOAd3yzU7aZyCIYaUe3gpv9PNOg9HX5qakzRfWJovAqnWLJoD+V+eJL1+XEIOkUL9v3Q
5IX21uqRsV6u6PngqUF89K6/Ep57azt4n1PRK8HGKuxFuyG8y79Q1psVJMZIz2Z6EW1MVf/k
yd0nqOpp46B6eppXSb9IpPeznq1bgQHZxAdmlaviHN76p6TMw3vT2EP59NDou9pbBfRWSf/2
o23kor/TdYJAX916vW1D1647dRfOKdDX7Xsk2k1dXWfbd48enTvXeRTN2QitsmHTSOL3mb3D
4lyBDPSLcx0TPkvt04glIqjlv/zNVz5RHknEKyXJ+26HMoDq5YERvhtsgeVTQik/PqQcN4Ui
s358asjU9oLJIup6asVOTU1asO8rjLmxZgXQtAQVyIK9B3rLYGkNTQ0gydiZjZX5WG88Fu1Z
quE16EmYVxIOgu/Nc1Kfsj4i75gaC6A8jurKCuqjQR/Tjg2CPtxjmVTTc2HvWevv83Nx2IBs
0iP7/nYnbvjwsT/5FM4ZeG8oof50a1d7Wwjo2VzZ0dXVCOmm+vSetrbq9judXNKfw7PEnevn
zpF2A8zXtZ0D9B99/fXXp9//7eUo02XN07T9haRbk7099gpkoF+GB0hRb+Hzz7bWbFr/tz7I
Y9F3+ezpkdnL77/3j8T2kwMHacW9/UO6ns/zBtn+IbB9qqhfWZok1leND0N9B0gF9P1jQ8J5
asZiHJZSb9RBaa/zKycA07xU8SXjtoGKY+8eMXZ65JmpM4CYHHc2VkQcL5YANnrdlxXJRnkr
KZVeHUC9T5qw/LpBQb1I9VLVL0FJn169EdIL7vH/Ib6L/tf5PY6rdthJet3H/uRkWxeE+s7T
WDDV3tbqr+hJoodyUw3Qv/dqV8eFh3v2tJ0gqw5K+q9Pdp7qaD333Wvn9gH0dXe2nSHQE+m/
/vrCjXejDPaZDWd+99wcPyoD/Rwv2JzffbA5YldUTfObvp3LaLyOzvnzL+UHKAjcDFTyHGAz
SUVwsch0LIxPV01yLT+B1mtV1ZAWbfrHUObzGfaI3k+avTFYTsJhqS05g4O95KUvjgKlan8g
1fETeV3YkxmHO7LWoU5sb4nCbmhkCuNSTgqCFnGU7RIVvaTeGLtor5ZwsG2QD4G+d1D0eanq
RxTqnyipfilK+vmQnkB/n6eru+f9OCg486yYnf0MQ7JIuAwB/duPzpFy00EVPYMeRfuFusbq
E9SE/foCSv1WEP8R6nyA/sJpXdKD9N99h7p+U0Rvtrt5AauM5327X6wPzEC/pPf3/fURQ+G3
mn1ON+yAnV7Sb2Uen1xZ6MMcN8Ngf6nKtslPTtdXTfIr8kUG+5Q8BaDMHx0C/KfIcFPwCvgS
RqZsf6XAXgjaT7pNn+u3sYyVvSUH9BOqEwvJXs3GooHr2zHFthu22JNWM8JxlrZ/SEecMevR
fKW/TVVP35egHjBmV/38QJ8g3likTyffSEV/X9ZNtczjDtYfMuiU27mt/6bns46OxkYt3Xjr
BB9t29cK0Fd3NbZ//t6JO/vgrDx3elfXibY9qN331NXBgkP+m9ZWEunrINKrip6q+u++bjv6
2+YICfPW+kzCWcAdmPyhGeiTr9G836MqIuPg9jU3AAqpBuvK8HH+36tfRbb7C3osHxmtwitH
BeVj6LpyUV81XTXOCk7vKOvzVcNjWvkujBE5x6ZIny+WlFJTKA4ZI73YKyf6PSe9ar/auLd8
lf3e5hG2VtIOWVojqy300HB8h6t4Y5aHD8c35utJOGS24ZsxKCq6CPMzUtVTUT9gvktnH4q7
rzxN4o0bhTB30gvo60Vfm/fjlD7w3mW7Zdp9oLPnRg8c8rJ2yuyN/e7hvuOo2wn0m18F6CX6
oL2x+jiEmm2tHdUgPl6lQG9V9AD9OZxt8OE0R9Q+NzMWLegejP/g7OIu1cXtj/BS3m5yJxRv
l03n1X8l1NOUG0JPewQJ8lVU00vFXqqqr0e9TsSfnp5WqM+TWs/OGy8OYYgDEHCGh8hlSUdY
r0PNyHYDO47GKKaq/Ad59EaxFwf9KBX0g7wsXFBvWO+LvGHQ00pZ1YAdCCQ6WCNTAnpd1T8R
1CsB58m9ESw1lBMEfVw7NqmknzPpBfT3uUyev3ij7vja7TctlbHhJ11t36ngYg/07LkR0L9X
fWfP33H9Xg3nzYV9586c7qiu+zWB/vp1ROncufMLT6RXoD+353rr5o//8Vr4LFXuWvm0p5YK
Cyv1eTPQL8mVv3c+/KHc0OLYD7pbLpevOlmURmzOioUp9fePgfT1E/0ItGHQT1ahVC+A9FzU
9xYJ9fJPekGdcSXxlIaooucDf6WW7Emwt0k/RH1YdXoDO6dIny94A1P9ExNEVhBfg55HY3UM
woCVeEOcp3ofCr0W5ZWF3uSbmX3hqOIV6bmqRx0vKQiqquembBTpTWM4pKSfC+nTyDcC+tpa
Fm+SM2+SH+uzVnZBbv8BzroxFb246FHQV3e1tx95r7puz9tkoIdk03Xn9Jkz5053dHSePMcj
U3DS3+mwRXohPW0hrLvT9f5b/3gtfJ3a7fPZttnke2ke75GBfh4XLelDiuGSTfdth/63dyzs
l+2k72Khb1dq6nltoYfUAc0Gakx/1ZAuhsfq6+sJ6+P4u4pK9zyTvkp5LCe4ETs+oaHZ1zsm
sWbirxzSrO+dkJ2x7KQvSR92lFUclM7ubKx23XhRCJRmxpW9HOWvNKwf1CkIqqAXz02/Kusd
1Mu3SU57bsea73qEK22u6pUBx9NvFlzSOx5LK7MYX9Gy1yT88yk/Jy9OPTzZ5NX1uYt7rdlY
lVwJ0Fe3d/V8Xr1vm4AeKTm7Oved3AZ/JeB+jrqxBPo7x792RHqSbvZh3KrjBJ4n3n+ryvo6
th2tZXKhj9zs44NXIAP9Yj8q7kcMRjXY5pvumk3lW8rLFVEzsbdsgQMBllUAvZxiFSyTU4r0
w9Mg/RChcRRKPbVixXZTmBzn15bGq+DEJFROcFmv/JUQapSG06smZItUzyu/zUSvSCPw2Adn
Y4F2seKQ5YYEexf06MaayVislFJxN1LQO6gfcVMQ6JtV0rw24ZCAw+o8Fsn2KaEeUr0U9TGg
D9k0Jb1g31G2ffWX+QL0j9SoZ9379mI9lp9aen33V3+mS/q3v95D5kok3HRgYurzDoCeSP9o
z4W6XbSKkG03yEMQ0NddqAuI9AjKaUNQDoIx8Tnef2t9uL2++/KTxbol2edRVyAD/eI+FKKK
ebtkweKoMmy9+q6DXisFlUYOID8pfynO19dPQ7uBasM1fRGkrxcbjpjnPdeNVnHGp4Tq+SKy
zjwnvWekLxUnh6iO74ebXpF9Qi0f6dejse5sLHVnWSoZ0N1YU9JzK7Zfr5eCkQe+G3pJcZ7L
etV/xbQUH1PD6x6pqer7lJd+oG/AIz1CEeau0i8R6Z/wA2xuSQhxj/xae8Spe8vPWKV/7etf
k0SPgr7jRE/P5uqTAnpo8qfvtFd37NuHJwEC/WsP29oQd3P9juWkZ+nmDLYQkgu/vf1EdQfe
oe393zeHa5w3hxb35/KF/2wZ6BfxIXD/cqjwaA+AI7tsYhG/4tJ9qmvy1NTEBIQuT71Xo9gM
V+X78wD7FEp1Arwm/bQU9XltnVdifZ6t9STiDFMUPc7opAE9+W6GtA+HjYto0BrQQ8LRFnro
O1YIgjJYcsEvqjgc9rZ2oz03eT0YC5yD83paSqp6PRmrynpNeooqljR6LdUbg6X23rD/hpqy
cy3pk0lvt2STinrVjb1fy2vA5p6EEPMAGrRbpocPfPTt269tO8nmyuqOjuqeRg/0j67DeVNd
3XahDf+Bo/4R2W7utHV0PHS6sV+f20YSPVq57bu6qu/UtV4/+XBb29FfhUs4Deez9YOL+OOd
gX7RLuZY5MIoXc5jpUiZRBsk3miVTtzNHkSq4k0lD+gP1dejuCddHmbKIv6qJ76PTteTPs/+
ylEB+6QipwxREemRiCDp8yUZmVJBxcPQcNTMFDR5Z/cIzUvp5msedb0S6QX0RFnU8moydgAL
DJ1cMzUrZYUgGOXGjEzpHEsq6y3QWzZ6ei19y8pLD8KPkP/mvnJazpX0IeKNT6d3SZ9Sv+Fy
oinxjp3TO9hZq7ljfwoXvZgrOxCJ0765eo+q6F87c661o739TlsbbDcnsYhEQB/sxirlpqux
q5pAv2/PNjrtH68PT8O5WV7jg3O6dOX2zhnoF+ceuX8+3EXgSTa3dzxbnC+1ZJ+ltq/4bPv5
5mtNTS016tZc9lsQx6an4bwh1aZ/grQaMHCYSE9IHwXnQfphxiUsN+Ms00/wf8cE9dyHVVpN
r5VIz7abIj8FQKGnvSW+dGLjoEe8mRziPOk63IgdLXhlvRVgaZz0XgYCj0qZI4qN9lta0s1d
prsAmIMs5WiD5cAgldqgPew3YUc7b8KMN2ElfTzpU6Fe4ioWvfPz2LJcvrP3QivMlZDXsXdw
1+YOAj1rNxBrNnR1dd1BmKWA/joi6dvq6lyRXik3HV272rtOdJxqO61Av23bSZqatdVN/e+s
rF+sn/YM9ItxJSciwmz04xXRZYvjiFiMb1Z/jtrB0frtlzdd23GzpabmdoMvPZO/9dv2UFG+
ahxl/DPk3hSolkdfFn8R1elvUnF6+8cF9azYFLi0L1BkMSv3nHGmffSqBQtjpbd7RHlw2LUY
NNAX8fQgSB1EXS+gp0JfOE+9WFXWYzu4oN4/MEXCDR3djbWHY71sM4Y9im6R5yXfjGJwFOk1
6gdR3qNTKvLN3KamQhuyftL7ivo0qGex+9ZiPkLkc9lyfffWv2SJvvPOrq6enSfBeQ36NuTf
EOg7r39Nthtsla1DEALbbiTuBgfKDWfZA/Qs0UO5Mafzy986sTsG+01ZmvFi3KcZ6Bd8Fe+v
jy/mu2+WT+91YOjp5eYdN2tuhXI9UFPRZBSfKTC+ahYvVj2rJyN9fT1ewaINcJ4nmZ6L+94p
Jv00j0/RUX1ZJn9+UhLpZWRqTNCJ8Hq1e6RIr+gtDo0inhgnHzIYO1ZQSEUeDkBP4n2vFXlT
yktZP9LLqA9MxpryGqtItPVG30DjoOdsGwN6OHAk8kZzHn+LSj/YN3iPSR9e1MeW9Glqej/p
k8T6+0/6+O57uuDHc8gnmLFc7199CuWmrrOruqfj5GsG9EA7SnoU+9WtSLJ89GukIdS1XfB1
Y8lceUqBniR6UW702fPmW+tCJZyGLB5h4XdqBvoFXsN85PpX/rkD5Rf4BRb84XfH1p0H3FtS
wt2ifUsJnpsi8F58hl5s/SzR/tkz+CuJ7EAkG22oWCfQ148TzYelpueeLAapzMiUKu8N6GG7
YbIjzLJIZf1kkbGPVHqoNjIai4SFkMFYrzVbIurb2WacgMC5ZiMzFGLpIz01ZRFBz3E3BvWW
NKU3kYzAYoN1g+aonYLehqlBhjDMlSNCespE8J/YqalQ0Adq+iDqE+p67hEteD424vG23gup
OfzTTnC8q+eOBfrXHu27cwemya4u7a+s7tzQ6o5MwUXP5krdi92354yh/EOcbejM/mNzWNWU
ayq/X4gX/HO5vJ8gA/2Crnd9RG6H0LL75pLUV2m+4/ya9c07mlpu3Q5TZMLUUPW6HE539+HD
9GKuAJqXnsFrU/9soj//bBb/AujRh2VPJeyWmu/kpgfzqZk5Cc6LSo+jerKE+2HudGLToB6N
RSNWByGMTg6zljOql48UKdQMRy8Jd4A/Ye0Id0Is2UlfKqipWH/WDSk3MNTDU8naCeaobO1G
+Su9RqkH+l7U7jhPRkxVD4FeUD9wVxX1S0P6ENTHsp77sTvSPDzm8z55zx3TvfVC9RFV0Svt
Bgum7gDzu7rayF+5rbWtugMhCCaTnpSbc8pcuatLSfQPXdAT7H/R/m54WV9TdpF/87mGK/cx
Gejnf+3vn48IIFaUXzf/Tz3fj8w/vnytqSY93Rnr4Prhl/ZfvLJ245atW7dsPXTo0F5GRnMV
mD4N2Bdn6T/PZsH2+mfPUOFT/xXtWJJwxFvJMr3Mxk4K5ke5KduvjZaQ51m/6YOH3pqNndTz
Uizb6NlYclfSfCxbLcPKep1Qbws33siUCbuxWU8pN8pDr+zzA9SX9TebdVlvVfT0XWPpFJlt
NOqVl37EK+qDSv3cxRtfwhk/u4SfiDkqnnHLLZ0rsXaTMb3nvvqLTzr2kXSjQQ+nDQIvGxvR
jSVn/XH0ZZF1zCNTSqRH0A2bK/FswBL9nm1nzumSniCvDvKMQ8v6hvPlP30y35/bpf+4DPTz
vcYDOyIWpEktP89FEPP7bnrXEN9vparepWJ/SbiOP/Qf9xzau4VvQxWJNqTX1K9hiX4Wog1A
L7abetLqyWFZPw28lxj0amBKl/LjnFdv5JuqKeg3JNUI6pWRflIpOCzb2OsEMTMbIdZTK9Yo
OJxrpvuxZjiWR6Nwek3WDdX5/XpFeL+kEg+gqveRHt+xSiz2IhD4CWqAoatQj0HZuzwsK0U9
GXDuzk28CVdvgvJNFOpDnwDusuyxyBZL9xE57anoF//8gg3617b9GjtLNm/uwDbB185ch9u+
rm1Dpz0yRS56kujb4bmHRH9hz7ZzwZKeNZyOL7eHqfW5awPz+/nIPup5Bvr5PQiKvO0h/HQ3
PZ7fJ53rR/U+S8l3Bff9V5jtTHb5y894Jv4BKegvz3LbFSab2TWE+NlZKPYAPV5Dw1L1U+Kw
FJke1npivkxIGcWGlHmkF5szxYNRec67MbOxrM6TcKNI7+2N5b4sNVx9XkvFeZFweicCpKdW
rM4/mBHUs3DDofQqAEGtBrcS25R6g29ZBBwr7YZRL9ZKikHgfuwg/nP/PnIQZri+fhIQ6uNl
+tSkjyzrQ1g/xQ/Imbk+jub0/lZj9vABq6J/7bWT++poXvYC+Sv3wYV5CvOxMFvqil4kesTk
wHNTfaeNXPReRb/NKunxzz17bnwcGnvWMjanbzZ7Z30FMtDP47FQuz3aZ9PdtGYen3FuH3J3
+vKOlqT6XeD+zv5La7fQoeI95I+NevUkcOjAWsJFwzOMv45zLb9mlmg/+wzlr4BeNBv8LZKN
8ljq1Ep0ZDXaGfwW6ceF6qNAvR6N9cQbpd1YC8KLRSQi0Oyrg3rF+YlRZa7H6nC3pFdOeu2n
RFkvwo0FepqKFZ77UI/vVz0H3GVbpa3VG9STSD9AsQggvFLqQXqffJMA+gjShxT16VEvuRUL
WUGS6oHoNWa7t36kpRuA/mRd4+bPG4+fIX9l56mujrbWjuNe3M25X+/j/ANI9NV3Ojec3vfw
TERFz43Zh51HQ+eobmdbZlPdSb53ykA/56t2tzlSs+luWtpAyplnm3a03I7rDHyfy0GX+Qql
u3uE8TbqqXZXso28mg/9dYBv3/l6RIHNzgLuz9aA6UOzJNQz6PEqNlSizBe/Tf0E1HgSZkiq
IbbrQVj0YPl1Xk2PcSlGfVHvB89LF7bIf8OBwwGWfKSM15ZKW6xn3YYMlmKlp9QzKeutqGI2
WOqyfpDMNr0q2Myr6sMSLCE38Qoq/Bca+YwDeh1eOUDRZqTicDGPxJsBLur9lvpFJH0068n2
450Sl/T5OT+m5/oBBeM1y235gUY9VsN2HNncU0dLph4i0RKgvyOgZ5EeEv0GL/9AJPpQkV4V
93v2XL/x+7CyvnvTapkvn+tlXcL3z0A/x4ubj5yNWkrKDz7e1BRLeCrf39m/duNW9FIPHACw
AydYzjPbPfFGKzmHLhIsbq8Zzeen10CQn1qzhow2DPoCQP9MzUrBZaNK+/ppxcP+SURXcnPW
OyTUW+6b8fFJZnp+iCIQmPoYkcURrb7EBksL9GC9cs+bCEuGO4amhO38kptUrKOKyWCpN05x
Qe+U9AT8kKqeQU+3Z4CLa5NLT+oNjp6NffKEXhok241V1Lvum0UlfQTrXdDfYxdYzRwf0/N5
9/9i9urkjn0k07Howba1N27u+DVPyrZ1VWM0VmZjGfQi0WNa6kTXzk4l0UeX9CTf4Hz27vaw
hMum/vl8zy/yx2Sgn9O9/yzKTplrWRonZe86EN5JOHb6AsT3/V8d23rgkO6nEuf5JSngzQmX
bcI0+kP8FaigRxVPMv0a/i+Dfgycf0ap9FzIo7TnfyjNpjAlaTduTV9FEQj9psYndV6hflLW
hcNcSWdySEScCS3dWCkIKsOSxXrOPejVw7Gqqiek5lHVB6KKCe6K9ZxL7wQgcKyZCDjeuilW
buSJSxz0VjC9sF0V0Pzd9pGX/j7sN1zc++WbeZI+VL7h7yWoy7ugf9LLd97QnB7U83znWuON
Mag/c3zXZhHpz7Ri7xRsN97IFEn0mJdliR6em9Z9D52K3ifSs07Pp+3of9gR8jtszdL+7jzP
a1K+H5aBPv19Uxtlp8zVXF5051ft1KYdNQ1RIhEDfu2WQ1y/+87evXsP4Q3Eehv24RK9rx1L
4H+HC/pnoOCzNey7IeVmdHZ2FtV9kUCP+l4kG0xRFTAoJcnz2DlC7VgiPZQcW5hnoV7NyMps
rNJvWK1Ra2Mp7Ub56kf9JT3hXTqvfaVR0ux7vbgbLutV+kFeSze6pFcjUzoYnuyWftKbqt5k
FbNwL8esB9cvC9yFt7JzanCABmR1Ue9LRDCgD42mV5vKw0LOolHvh70P9Pd4rmnRgukTfjjM
HjWF+kcnqzdvbmzbtg3+ytaOLqSc3TEBlkqiP+ElV0K4sVR6txtLLynSozH7y7AdD5ndMj26
nmeum9QX6/6mCOrebl7kJKni+WjEswQPYyRZ3iHTkOmdjmb93gPA/F6U9ER6U+WrLqu/Gesp
8469kmvC7cV8vmrNGqg09WtIvxkX0E8S6NGfHRVtHtrNGDMQu6fUgCyTnvz0nk6vFpJ4sWYU
gaDTboZ1gKVsB2dZp3fM1W5YrDdxxZRv4wO9QX0/xVf6EyypopcpKmwWDIIeqWaSSy9ZxXb+
gQ67Uck3JvBGQunZgAMPKBfz6MRycX/P8VkmlfRRHVky/SQcVdxr0Ov3HuS7b5lsX8+fP9W/
4uaOfQvF5td3NpPBct+jc/BXEujVbOwjjijWEj0iFCj/gDlvnPSRJT3xvgsKjvOrLL+Q27To
9VVqHKy2d8wq+nT32L1r4Zhv2LGYfq/8evRaw78Q1fAvHQThN5JF0j6mKBfcC+n14acB1XVl
Ed7Xjw266HkotgbCzegaLuXXrFlDg1IAPU1KEeg9bZ42hZMEDz89BSDokn6aZ2Rtsw2RX4an
dNaN2iKIBEsr14xQD5oi6caJpFfuSm2eV/W8SrDUhpuCbCAR1NsJlsT5Ad2XJet8QL7BrRCn
DXqw/cReVcDzXxJ2M6NCzqSkV4um7gnoVVE/I6R3fZZLSHpB+xPf88Fd9v02pHtUL8Z7PTao
3/p3r23rJNBfwOLYPZ13SKTv1CI9bRHcQBHHpNycart+4ddw0dsVfSzo9+ypO/r7kLCRXHPW
l013J2agT3OdBnitQ+DkWhbNSjm4vTkC8SD8D1+6Ar6D8PzfjRu30j/5jzqqIucC/wAX9MJ8
kusF9U6Fr2gfXtHzrVyHgh6lPAiPsv4ZQPgMoIdSM06gV/5KbBKk0zvEHkuy0NOScEk149wb
qyPLQj3eUycVe57Kgua8XhAOqZ5DzQJRxV5bVhR6F/RefCUvIFGkVw56bsQqCw7FILhHboae
kyLB3ga9Rj13ZTXn9UZBKurpuxWlXlScRSN9YlEfBvp7d/kOnE3zsF6k9zGo7z6wjZz07W0P
tz16WFfXTiK9DrBk5aazGkE3slzqJJkr40HvaTeo6fd9sOH9t8I8ODuWdmxgka7Rin+aDPTJ
d0Fv+EaRW5sWZdj87prmm7dCHZOkwx9UbHf+2qo57zdRsjmS2I7/KtRDzOE/dKS619NSynRj
9WPpny9xQV+VzxdR0OdpWIqUm+IagJ6wP6tAP25Wx/J0LHVkieQa9Ez6fpv0LNRTVLFR6MeG
J6msR2aCDrDUC8Il6SYYX6n3jwwMYLNgAPQo7UuDuqo3JT076JVWr1A/GAZ6U9UD9K59nmal
uGzmYEuvomf95i5SLHmhINtvmPduSzZRpg9PLdbCfZKAE6jo793nR+tyqfTy02NQf/gnjY09
jXf27Tv3sJX3yJpu7LlfI6L4TrWR6Pc8FM57vpsYkZ5A37qhbud7714OcUNkiWfJDMs0+sRr
VAqdge1uKiV+ZOI79K3fUROB+B/CKhl5AhW9Za4RdyUfo96TmsPKvVffu6EH1kssHK3jTuya
4TwV9GswAouZqdlZslUS6Glwis/EOOR6ZaXXY1NS0UuwmZdeSalmRPrSVNW4rJgqDMNJP8z2
ygllu9GcpxUkIan0Y9SNRVI9p1YOFMJAT9HFTNY+lUlf0pNSGvWi1fuqeh2DoDeQ+EGPb1yv
ILFBr1IshfTKdiOktx31CyR9qrLeeTqQkn6ZKziD+ot/2d5z58K+Mw8Ra8Y7p2Q29hGbK2lc
CstlaSxWPDepRXoC/anqE7s2v/w3IeEILYvww5j407q632GZHw+r7mKNh/SAvs/VLHgL88j6
a6GMz5GbBtw1Mk0I7bco3cbSbjwXJThPmrwVYUMyjjRpFfBZ0aF+rf+got9PkLg1SRb6NbNw
H6Kgp47sM4D+GRT56Vl4KYWLBY6sBPNlOha1PPqyyLxRoGewO6RX+0cmuN1aVCkIk1QjK+eN
B3pMSzE+MX5lDvO9n9uy7MAZLPm1G/HVlySUXmXS86YRO684L6h3Fk1p0EPAEa3emZMSHUeF
Fdug75NN4fBWSlHPwo2cJ9aU7EJJP1fU3+fKZAk2kMT/8JqtDMc6TrS1PTwD280uiPTVMjLF
+QcIujkh5koZi03SboztBv94RX4fwO8L778bYresGVp1aFnebzgDfdz1rg9bUd/Q3Leg++je
umstIREKQPw7LMVzEo2W40OrenqrK9J7oAfC9biUZ61XvhyP9Qr1ljNHvTMX9NsL1IldM57P
Y1iKJXrwnhMQhrVio2w39Ugu5rBiLd4MG9Az6Uu2eiPrZInsY16u2WSJ2Mleehv0Q8UJiTTT
oOdpWB1bzF56MtO7McVqOJbXCpLFplQiqiPixjmUU0yot9qyhvR6gWxAvbG6styBpbAb+ltF
mynUW6S3AhFSkD7GfSO5O3M5A1zSL/++1U3qt9Pc3o7O69uQT991oq6uo423TGlzJZKMEWhG
Y7Ga8zG2G0uk3wfLzp3qXY2fNLbvqr7xbojd8nZmrI/DUgb66KvzNAzHLQtpc91/3BzCeEL8
g7VGqmHQR+s2YLy/orekehLnnblYE0/JnVpC/Y/Mf7Q/R0v3W7d+w5YNeBDRiUVBT/oNe+mB
ex6ElVoedNeCDfR7Tjjjw5k3Wrup4sEpayZWL5HtK3Gomck1k5UjIL0DehT1gnqG+xiT3VLt
ZVq2PxT0aMX2MswxzoQdJIFNU/l+zra861X1BvRU0PdJVe82ZPkZiqV69s9TKS/FvVvUe3Hx
dkt2EUgfDXu/7QbrsPi30OUYj/X97NzX07KH/1xA34XR2E6p6GmLIJSbrhMEeiRXmoI+nUiP
XmznzhME+l0nqk+1tb+7PijWNyzNzOKCqrqy+eAM9BF3Re36EPW8u3neOam102B8wDkJV/zF
tXw2pgc9kT6qoo8IQGALpphylAMTwP8RMV+atsqFeYi/wfX9+XEAfloKerLeTFUNaV1+rKre
5FcS3Ev9vbodWz8Nb41sCCczvZB+wtsyJWunEElvLR+haDMZlC1aoFcpCEqqnyiOcgFvd2fH
lK3e5Jn5soq96AM/53lmSi2a0lW9EenJYgkBR4Zlw1HPtTxV9ErFEU899k3xkXYsLxn0anoP
9FGDU3GzU9ZAVVhdHwT9PUm8WYmUgP9ZWyD3//kest3QyBSBnlz0ElF8AosISaI/Zyr68Khi
bs162g0sOyTRM+h3YnfVvs6P/yaoqnZnSwejnlky0IdfmbAh2Jr5bhKZ2nQz6I5HHb97IxOe
IG+RPk1F79puvIqeTDcHQoJuSLP3/PbiwqTanv8w8Lm65xz6BoBwzWNI81zQc5SZOVX1bLtB
XjHHmuEgdF7LOOK8UWtjOcCStBqdaDYpe2QLkG70nimTVMxuywl/SY+pqTFZIEucNyKOZJ0h
6kaGZf2o19OxCvUcZeYeWS0lbhel36gbyJU8/Vu8liFNWWwLJ6+NV9HjG5e8YqXeyNIp+Y8R
6lORPkm+iTDiuKCXcQBWHJc8xDL0J6ek8Jvb0tp2oh0qTQdF0p97iGYq8g/0zpGT21KB3iO9
SPQMevxGsOH6PnLW/3PQJ5GhPoL0GejDLsz2YDWfa5rf/Gt9SNOVO64a7wbzuqRPBD1T3irp
beWGe7HBRDOVVMx5xXqg1tT2P5ID0ktsJYSbx4+poB+tnwLS5eSLMN8UMDel0m50CxbPA2q/
FGGfA81MRV/FYQhM+uECYx7+ylGQvqTWTOmoYnHf6BVTXoAl4m5EvxkYKPk2TZHpZoJJH75m
CvINS/G+XiwjX+yVvUxW3jOlfl2hodhBubmqKxss6jFA5WTdKMUeXJeiXg3IMunvjczwd0ih
a4mTUymLeq++V+W9gN4q+/HPZ1zSz/u3z4XpDbor2/2zLrbdXEBJT6AnUkO6IYkeUfTnPNI7
i2P9ufSqqIdEvxMSfWPjLgJ96/V9dFqP/v5m4Jfk7hVf0rywy7dEH52BPnhhQ9LmGy7P4/rX
Pt0RSN4D478QrUbV8h7nU4PeUm5Yr5f/yyFpJgL0qqJXW0csCyYX91zZEx66YaF/Vj89pTd0
EOQnodfQmGwBc1MEeoxOSawZsR0jU0alr2dZ3kf6oSox3LCNvmqcyveSLdLDZjksPdkJ35Yp
yjUbZXz2+TcKio9eFk31W7tHTLAZc54Wgo8MmjVT2mSpbpuSaKiqZ7qbgp7mfSXD2A6vVNTn
tSOedMOkHyFxHnnFTHpWbyQPYY6kT1vU21j3MV5K+qVfNRXz81Crp8iPYcsUurEA/Zk9+9rY
NcOgh3JzxgJ9Cu1GmSsJ9JDo8Qn2EOj37Lvw/m+D87IN8/3Nex4/46vmQzLQ+++qx8EW7K3h
Od+fd9c33fIVG2D8S1c15JUsz5g3f6QDm6aidzV6S7qJqeg5z9KNpDdBOWK/5PSDTUh5tCaK
xsg9T1K9DXr0ZXmbIJ1pQFHrOFg7BRoOW6CvIsTzXvDeIZWJwKQvcE1vtBt4bli+yau9sV5U
sdFufNtj9WysDFEFFwqytyYvPnqJoveOuXkq+aCvn0FPek2fkes16sP0G84q9paFU0+WuH6X
ivoBmZ0S0j+ZK+nnjvow0N9dT/dkbs6P2sX6gD6lqXT/pK6NurHntp283ta5kyT66g7eOQLO
z0Wk1xI9gR4S/QdQbrim37fnwo3fBt2WDQtxTCzWRSivz5OB3r0/qoKYb5nrjHXf+Zt+WyZ8
NQdtxuv+67xBb4w3bkW/NUG6kfhi88cYMGW4ShX0moOjVeS9oaAbG/RU0jteG2jvbKmXQ7K8
lPSqC6vqYHv5CAk1zj5BHo2VQSp7Q/iQlPODqhkbWCjIRX2JFfxBS6onlR4OSwzE0vIRUXDc
ot57IuMMM/AdpOeFI6Ybwd82YxcBOL6jom7YYKmPJNOTUq9KekV6s2EwnXozZwHnbijo/xfW
HjetHGvWqZ+j/b9g0EO5wRbBEyTRK3MlQP9dspNei/RsrjyhlRuW6AX0QP3JnnebA1Lr7Qxs
PrCt3GOhDL/yVMA3n5vjquXCJr9/EoU8jDVOKW+kG6ee1wbLOVf0di82vqJXg1Sa9DrzRo3R
cvpB0/8JKTPD41Wo6slbuWa21J+nqSn205co8kaFIJgqHqZKrx3L/dgJJj2DflKqeQvzpN4Q
6XsnvZJeZSBY8o3EV/KALJXyY9x4dXR6VdLDSu+X6mGvZFFcTccWWL9BcGVISc9dWdV4tYQb
VunpyNNAwH9DpptAUT/DRT2Rnv5W/7eSb5aK9K48r15q5rb6Cv6I1e6QX2hze6uhx++5oPIP
WLkhc2VoSR+VggAX/amdJxj0/Als0O/bd/LCZyHG+tvFFbz15felsyc+7z4ZC1hzu5vnco8N
Nbf4Kotc9w/PBgp57xUu55XBEjp7go/easWyhONp9JJ0E6nRcyc2WNHrtBv+ySxQJ/bxY8TR
wzxPoIdKw/9Qi2MF9NZALMKKJbdSHTJRTlr+SgamMyKLuBtuvg652g1tmeL6WO8TlHJerYtl
mvNgrM6ytILNRL/RUv0ER94M6ribEm8Gd5uyTtqNQj0R3TIYqSqeTPX28hF+NZluJOrGrull
NBZKPf6eIeXmntgs59aRZYv/gs8I35kr+tM9rH6cvvrFtodQbkSiR3IlSfTM+fTajSvRw1yJ
it6U9FzWd368KVCk1SxmsOxcQFCO77uiD4WyuiDaF8Z1CJ/uOQQdDG4KQP7w/mMbyT8Zefz1
vOrGcupY3MCUZBWH2W4E9BGmG5m4dThvLYvduvUq3eZb/bBW4sBzI8o8QC/EX7MGXVkU9Np2
48k1UGtM4A00e1LlqaSvGmMo5qdIt3cHpwzpbZHek2/GyHcj5bxnqpSZKT0bKw5LL+9GFgqK
flOi2nkQccVehKXoN14Wgi/WTA/E2k5SKelFv7l3z9VvYLyhaSxCvSXfqN2xd7mk58zie2Kz
nDvpF456VslXYGjK/plWy5VzPzp5HcoNu+g5ongfeW7SgV60G7HskOmGPgFL9C7owfq6j80a
FPMTXFMoK8Ss5DeTgV6ufiFgyW1Ijfnax02+aiJ3+J2ra4+BxXGcd/V5ttJLCPEcQW+V9Az6
KHel8lZGVvQqzqyKOP8YMcUi2MBrQ9NTgnxOKybbDayWHttJrfEqehZvRqdV3kGJOrCTeA1H
FKtDfdghqemNwVKpN7JPED1ZVc5b+wRld6xFfof0JNUD70D9hOa8nUrvb8r6o4oF9eyht9qx
QnroNyq7UqEfEfVmPlYtmuLKXm8JZ9CLVB9J+pjRKWULXVhV38+6yQo5LDXR+pSp/isU9JRz
wxI9do6IcpNepJfgS63csEQfAP0eoP5yoMPWshJjYysJ9KivnYGerox2CXjVfEPaRlah2RdO
xt4a+kPWx1jQB0hvTDeIp4zNQIis6CMWg0uNH6jojVbPzy38S4wq6Nfw3hE649p0w5k3tH9E
dWMtXR78s9qxbKaXenhMkZ1ew2tHLNJPskrjK+nV5hHknFGomT+TnuWbPqXl6Ire5N3geYDC
zFifp3reXT+i9JteJdX7QS+xBy7qdUmv90wZ/w1FIYhmw556r6g3o7HQbhZO+oWV9cy8HSvN
HFXUd7+Ner5LgX7fHuF8au2Gg264oBdzpYDe0W64L/tKx7shqF9YMtVKX8DF+voZ6J8/r23y
AK9Em3Q7yu6vb3JLCAxCXcVhzi8E9PGZZj7pxq7oY0GvxmNDS/otW9lb2ZyXgt4oN7xdSpDP
+0a0dkP/NgcVe8FX0hMkrQ7sBD0XuKAfHyZSjg4L6q01U0OyfArqfHChoBT1KgshsH2kX/c7
+8I2ChY4t3ImlPTUdB1gsBp/pWrHKtrzVJJuytKAkhLnWb6R7bHyTbNuQ4e+U3LXR+r0yTX9
gtT68/zEvVicmPfnmRClPre3q729EdJNZ50yV84F9Igo7hDl5sTOU0qiDwE9UB/Wlt2xwr/X
zPvaLeYHZqCvDeyCTdeCHb7mGuVzmHY1lCeTzdwretZukk03EmFsxVdq2w2ZK6PGpTTlQzR6
acbyj2MhP0ucXwPl5pngHbYU9a9o0NOYlGnHKs0G28C1wZIAjwq/39stKONSTPqJAOgnpSU7
SNsEyXrjHC7qe6Wo93w3OuhmolciinUMgr1RkCZiWRTpY9Q7JT0LN7IuFhHFQfEGt082Csqa
KSro9QoSvX7EgF7n3XB/mCjvqjcph2SVfLOQzqyMOS8mLOb3udT41FeIGAbo7wD0SrlJPRxr
JHokV6r8g9CKnsv6z0LMljsWZUXQ/G5+mXzUCw/6dX4Lbndz8sbh//7yTefDct3Q5LmOV+V8
OtCHaTegLrqp6aUb23YjLvoYjV6iLM0fbbehv3cTFlryRS7oPeUG/5pQvVgH9Igrtpw2KNhF
sp9WdkpaL2Wc9LxAEIDM+0r68WGiZYFreq+il/3gAD3vjfWDXhktC1TUB0E/KqCfyUeQXpnq
qSlrg15GYvGUJlvC7aEpT77p5exKasqycuMtm+KkYi3fsFFIjJZMem2ztMIsLZtlqqJ+nnX9
vZWJpQ/h2rD82tt9vKexnediVS82TLsJNVhK8KVjrgzXbpj019uDqM/NZ7K9TBC9ON/GCw76
scBk07XEJ/81O9wPQjgZVfIG8Uq5QUUfb7qRtBvvjwRYMnzjOe9U9FzNq5I+qaJnwkfYbrj+
Gyo8Y9BjNXgVYs1wjM3SWx3LIj1CECynDfVf4avXxXxxHM6bogP6KnJdetYbnVNMKk3eJr00
Y/tG8ddgXyjpZcMUR1n6tRsak5ITrt0Q32XvCFBvDU0pztN4LBf1yKpXiTcW57VSP0MF/T0q
7PXhSAQ9JysxCB7pyXxzF7hfGOnn4bgc6WW8zi+haXHgoj+LrEL5PvfTnsaunXXH9/0a26Xm
INJLFr0CPZQbJdGHajcK9b/VgclGlG14vLi3abV9thca9IN+q01uR8JS+fvrXRdlrvslgbzF
+fSgj6joE9aOqCXhIbOxWw/tjTXdyDbwMI1+Cys3DaqgfzwE5QZ1PQ7E+mFV0cNe2U8SPYMe
IQheDn09aTfDwxJPWZqaRlIOiTku6cds1d4EFZeopp80Jb2oNgU46XlF+FhISa/D6TE95Svp
IevQmFSBUU8bwn3tWBmYElN9rwd6rudljyzNSTlKvQN6vWZKq/WG9Lwq/J4q6pn0rNLf45qe
SQ+xPoL0aYt6/q5TGnFE97nLhfS1siCSkke3oKTvJNPMQw67SdWNfQhzJRKOpRdbDYnecD7Y
jdXTsvv29fxWDWx57bdb+bK4FCv0TbzAoL9/zdeDze0Yib0XBjY5GWUYeT1rKO+r50W6STDd
hJb0yfulAqC3KvoUoHfVG2H/1q0/5FZsPw9LkXJDbnoC/LD207OP3gM9QhCsbmy9ipqnBiwr
ONPw1iOZ3tkvhbB6CPdyNOjHp6iC7wXpSbtRqo2kIIzxtFRQu6FKnrPM8przynfDjdo+pN5M
cFO2P2i8EdKrFeFm7QhF3MxIfc91PEcUK6XeB3qRbUS5sWt6sdSrnqwBvTRkdSKCTXpbqJ8T
6ZNwb0n7IyNl0o7ln6miyDcN1Scke3LPnm0s4CQvjiXQKxc9J1emA/2+VzYH485uxv98rxCC
l+fLvrCgr73szxyLzyEuXHPmZnOHXzp40MJ8SEWf6K6UdSPmjyfdJEj0funG2G6SK3pHojcB
9XgtXYxcvsDDUqTcTBHvcRBKr0w3xkcfDEGYJvskzsS4ykUA4vHiuAt6JNd71htD+nGq6fuI
9JO8TbZvVCdYFqNJX5TUA9oaa4amGP69kmPJRf0gFfW+dqxCPW+YGrDSivVaQSa9XdQHSC9N
WT/o1aIp3ZEl6YZDzfjbZMkeJ3zpFL5TB8+L+AI/wseXByRJX+X+TRHqf0H+yNbT1/ed3ENV
fZrNseKibzf5B9Y6Eq+E9//r+vVXbgRQn7uW3H9LuiGr9O0vKuhn/aMVsZMV046NEq1XlPI+
zAc0eiq84230/opeafSYeEqj0YfYbmjrSORcrDjpqZ730x6v3kg/hLf+b9PMeaXcMOgBQxmc
Eo2e7ZVE+npsClfd2EkKBCPMW93ZaWK/1XyVMp7eS0dYGtIPM9+HhsdEtdGYZ0e9eOn9CcXs
uOFRWF3Ug+08N2uSzcR+0x9Fer2URC8gMdW90ua5qB8gpT4AelXTi9PSE29455TuybJ0I5W8
1PRqw2Ak6ZcI9axM3iwXMomlPvcTOCw3tBHqoeAgij5pRfge7KbCtJV20cNcmRL01//tKzd+
7xdnu8vAhrQid8iLCfqCP9Xm1nT01R93KX/4C7eQ916ybTc05poM+hCRfgs2/qUCvdboLdsN
z8UmmG4ciV7ZbrZsZQ/R+rxw/jH4JxIOgb6kJXrjuuGSHv56iqEfB/DpTLhWeiQgkCTvlvT2
unCvohf1pk+8NkVncyynIPSGcR6v457swKhU9PKCHUvP8k1vKbykN/pNPzsuveWxemGiDMqS
/cZPem7FKvuNQ3op6mfoVjDoVUt2hr8zSS62Uoup0J+H/WZO5f7dApO1bIrYx+JUO3Cn81Rd
XVtr6/ULJNYr1EduH2GJngt611wZbbCUhiydVz54/2/8P+oNLybyXsRbPSK/RXonJu2gykf5
3VcP+iWbQDc27bxUqEZP+58SQC+mnOCSqdiMYjUb64bdmNFYVm76x4XzUG6Uy9I23XgDU9p2
U6hCVj0d5BnXoxPrVPTTlHvgaPR4ga03UtN7pJ+akmIeqg02hDubY4t5TikOP5JoyUU9y/O+
TVPSk81HkV6Z6sVYbzlwtIneeOp9pGdvpSffWDW9kP4u9WQF9INcyQvpZZestYnET/oFFPV3
I/Evz98rUkGGfdG82NWOddy508mo12U9VfWa9H6DZUCi9wr6aN+NAv31Dzbcefm8/5f3mt6y
uSLL9428eKCv3eTDfLRx3q3lkUQJykeV8z6Rfr4VfYrsyo3qicDYbrRGz6CPlW5IvPEZLDn9
4CBdkhYZlnr8eJJ3CXJFX6UWhDuTsQx6RCPIKchucHDd8luiHVsF9Jf8pEfhrwZmLdDLzpG+
/iGVd8O9WDroxJaI9PZWcDu/Utqvo6Ms4/Sb9eDyD+wSlKLeizbz7Y5VuwaVVm9t1BKlXkUi
uKAnxs/09s4Yod4m/SBb6qknS6INfedso09J+nmjPhr0PPK9wslmNsvuipLy1Z2ODkI9Kzhk
onm47Vzkmqk9tkRP+QfpQM8l/SutG+o6QuLqd5TNbznLRvoXDvRDvuf3XFOEo3LSruVho8RA
FIr5ONKLdKP+zEe6IR89Cvp0FX0wv3L+FT1XflWqoFeeGwY9mC8hljgk3VCoGThfP6x2yebN
RkFyWHqLpgB6tljaUWYMfZJC+JWe70YslazT8zGcZ9JzuJmOt/GX9qLM8/HvCB+FPp8n0vP6
ETohW8LVpKwbWqyfwWRtrC+LXnnoZVCW3maDXgVaDkCwV6APkN7aGE7ftSPfzLcrGw16sdIn
WIaXjTX0hXbwd9Rwqhqov3Oqrk3UejRmjXSzzVfSE+hZoodyU035B3MB/Qd1yLHf9d5b/n2D
L95i2RcM9Kqk8Gr6lvAg0/w16/mAmq/UVk0AvWa8ijQ7lsZ1E7DdoKJPKd14oNcV/aGkpJvw
sBtU+XQ9uiWfmM2Vk0qst003ynXzrL5qSCvZdglfj2LdSjajQHryU/pLem7Icr6ZIr1gvpfV
Gyj0AdAPsfnGy6z0rZmSJHp3l6Aq7akTSxNUWCgYDvo8m29wwkGvi3p7lyAV9KoPS6S/aw3I
CvFZvrmH/0pFL3kIYqjn5qxjvVkk1EeD/u5KL5oKPonI79OH26oZ9aTgkFpPjVkYLvn41oPv
u64lespPsMyVMcOxSqR/Bc8Rp6p37WrseT3Qlb31guk3Lxbo/ZbKW6G7JWearQYOUf4s6vhk
0Nv1PN6dBlaTXDfBZiz1YlNW9H7bDdT9vbG9WBJuyHIT8Fjyaqkd/6OiO+Qa5b5hQ7023bCP
vn4c2Qd8yHRe9cyNMrOSzXjzCCnyftKTdM/WGwa9wjxCLPlfpNE77VgemCJe2itHbNaLbOPs
jDXBN0R69GRhpJSi3lfSG85jUNYJRNAlPf7moh5SjT6UV6z+3Uf/tqMQVG3P8g0pOAJ6zkN4
kp708xBwokE/wgX0rWWt2ZO+2Ho233S3dSnUo6xXjVld1jukp16smCs5KMdVbuJEetJuPqCR
2l2Nn3zySc/L/9kfJf5i6TcvEuhHfapNQ5jV6v55aypKKE+gJ86nlW44uzId6P2kRwJCatC7
thvgmyv6qK0j0oxlyPtmY7ds5R+9kqQfPH6MmVEl1hPojelmlqQbdUbH62k2dtIGvZNsRjNT
bLG0MyuF+fRKWjjlYX6Ic82I9P1Mele70RsFQzuyo1q5sQ03NuknsIWEavYg6CXhLC/jU1gP
7m0Mt0CvV8oquNMOEs4146PlG1e96eNEBDgt9bFslqE1vV+/mTPqY0A/yPXzvST4LuvbJV0K
pD/BrGe1XhqzqNFJwnFBb0n0vJ3KVm5SgH4ngx4e/MZAhHH3mmW93Sv7xV4c0D/xeW26w4Yn
trdYY1Td7zw4iyPCfArQ+yX6+LUjYfvBKeqGFofE++h1FI5vyVSyRM8lvW/LFLVnWTYtPl7n
em7wkrdQsH5KOWyQcVNV/4yc9HDbOKAHwce8Cl+X9O4SQSI9rQ9HgrGu5s1CQUN6P+iHioVw
841MyA5wUR/Q6NGOlRQEJnkvLwq318Ya0YYzEWaiSC+DsmrBFIfieIfdNzMmyFIDX1vqHdLP
RKs3Aal+jmJ9DOhHuLYps0SvYSH98a4ukJ5Rf8dTcIB6H+hV0A0k+o46n0QfFkpvJqfIXckS
PYEeQ7U7G9/yJ+DUvDijsi8M6M+7g7C5kDnYvN1+pVpeY56SDlKA3hbpF1LRJ9nog6DnULOt
B/ZCuomt6MVc6a/oz7JyM7tOQA/lRjw3OJJ0M6ttlLDLD1fJzBR8N6Tk+LQba9EUgZ4tloF+
LCWe9WIairlYJAFHbR8h0hdch6UkFQ8V2Xzjb8lKOQ9/JbvoI0k/UWCmg/R+zg8isJgKedoe
TumV+tglva3UU9aMY8LR8o2vpu9TgZbBml6PyOpfRPTfvqbs4k3LcsxHGfluuKwt8dMPk16z
/hSZcCDWS5CNh/o9JNHv7KJebJhEn1DSb4BEr0CPIPu6DZv/cNOHgTkthV7ZmnxhX/0FAX3B
J9DdCuwNvr/JFuZ/yLW8Br2S6JOkG7eiT6XRB6SbFDb6jVEV/YH4pBs1Ghus6LnAKq5ToEfo
geb8YyTdFBFNL81X+m/9GhmNJdDDeDPtlPQAuK8dW8X7YwMNWZlC0pj3SE82yzxIHyjph4Y4
+aZgyzdSzvfxxBQj3+ejJ4elOgUiORIrPdKzbsM7SBjuFGlpkd4Ffb+237C13gG99lmGgp6i
ixXqWb2hml7Z6Z+M+Ekf0G8WifUDdN/myku7weJOIX0rtk4Z1vMYFaIpXdSTi16NS7FE/4qr
3MSDXkn0XNHTxpIPWje8X+UboHpR5qdeCND7V0h1B36Xrbfy5XOHd0OWN4c9laS6K40+2knv
VPS0diS5GetPu8HC2MQ0+iDoJaUYFX18AIKS6X0VvQRXdk8r0FMUPXtvZuurwHl1SkOYhiJ7
pQY9SI+k4mEH9HDUWImWXNKTycZaNKUSzSQaB3sETYilqulLqqb3SK9K+qEik94y34izsh8W
e56N5Zd8TnqP9CWRZ7yK3nBekR5vhz5j5Bsf6ZVSH8J5FWjJ87DeEe2GAxE06WkDCZFeSnoM
TgVIH4b6Ocv1wdEpRmr5zEypslTV9PDeQKnvUmq9+C25rCdvPR/bRY+14H6JPla7eQWgJ4m+
kSR6cux8gNP58ibfBoqWcnsaXFjpHvHRLwLot/viy5p89+yg5aXMdX9hQd6U9Gy6kYo+ZmTK
sdGnA70bSU9p9OlB77PdHEoB+jCNfi2h4OYagJ60Gyg3VWtmp4dKBvKF4Xp23syipDcVPUCP
bqwr0rvtWAY992O9zVJsq1QJaP0G80a7mZqkIASoNyGgL3LyjclD4FmpgQmzaGqUx2QRXekc
b/9IgZmp1giKluPuFORFgv7MGw/4aqesz1XPz1cyJmsf8liyz9IjvTbUK9CHkj4U9XPU6/2k
n2kuR+3m+fM8PwEd7uwA6rt2tQvqd3YA9dSYlXxLsB5BNyTRYy+4SPReRLGp7GNyzSyJnnbN
Mug/aP3sY9/q0Fza/dBLQuBl+qSVD/pe3+9qt4bdS2v3X7Uwb7Ne92KVjT4N6FPul6J2bBjo
kyLNtIZvbDdS0RPoU0j0PBxr/ZGcm6fC+TWz0DImbLOhzq4E6Esu6Dn7xinpxwLtWLZY2v3Y
KWrFymF5Xm8gUQsFmfSlMO0GSOfkG56SlfQDd6MgKzkxpOeivo+LevrXgIa+DqbvI9LrNAR/
Sa/Ci/3CjdwQ9ll6e2P7WKKXlDO8Vgv1nEtP2g3n3jy5J93ZZLGeh77md+hDRbspv0lQUW9e
woxsByiPteGi1lNVL2U9o16y6GnpiDJX+kw38RW9T6L/4JVXBPWb/8an5DaET9MsE4OX5ctU
POh9gQfd7rP3SLNnucwd/uPZ3b5y3jLdpAC9NRdLG2NB8cQzD9CzKKTibsziWLLrpAM9PxfY
qKffd7ox+Do9XvTKeOB+sgqhN6N6LpYii3lPuBHpg6Anqru+G+nHmrXgwzRDRYwfJvF+OAB6
ZBX38+BUaEnPLVmq4nVIsZLsVVaxLA6PKulLJeWnlJAbIb5KLVZh9OyZV/JNgPSSiBBO+gEf
6SXcLIz090i7YaHeTrJ0aB/sy6rXzAn23mfh5/H/dVlgMqcvMsrf2Fedd6ioh36jynqwHqhH
OsIHpODsE3Ol9GKD5srYmalX+JcBpdywRK9A/8EHG442+/Sbis8vrnDQ9/qeum86C+H/yTNT
IuMgyHivG0vMVspNCukGFT2HjiViPqSiR1hNQkUvcfTWfnC1SJAXxiabbvwVPScUt9hF/OhQ
1TTUmsePZ9GLtUCPwEoP9NBuAP5xp6KvR5fVa8eKdmP1Y9UKqvwQtJxhgD7viTdKo8f6Ea7p
R0PasUR1Jn1Jkue9ABydSq8Wh0eINzDd8BpB/s+g47TUN571GSXf+EmvtJtw0rOj3gj1RHhe
N6XiLB3zDaXgSE0vGTipq/q0uPenKnC8TNOcGLw87zzNiuqWOoN6wJ4UHCrr4bdksf6D1jaT
RR8u0Ue3Yy2JnsyVUG5eUaTHW6o/9rmtG4rLc6tX6qtUNuhZoPTO7XrrMj9p9p4EulHMnzVG
G5f4LN0QkZNB7ybdpKroXe1GbPRzAL3I9Lxiimz0cRnF6ilA3sWq6A/T9VmnBAxSbYy5kmIs
hyzQT/pAj5eL8NNbB/j22rECehZvaLHUkHhtCmrJlARZ+rUbIj3ZcSzSm3YskR7JN0JGLBL0
jkP6wUjQ66LereftReFctot84wM9u+nZduMNTBkRCv+gUEu9IZzWTbFkzzU98d8236Cil3z6
EOuNoX5kWe+9wVfgR35EFd2/DSvFl7ivK72zvXV1dyDgUFnfvgsSzglCPav1UHAgvvBYLF4f
kn8gOn2USI+5WGOu3EUSPTgv2g2dDZuf+orApvLTtxbxXqtk0Pe6k7Ddtme26MUcoZjf/SCC
8kq6OWhX9GlsN1TRp0hACKj0adyVERU9rZdKBj3NxroiPScUF1Fk1z9b83jNGC8R9Gz04xbo
YbOhhDOj3aAb6xPpKYTeCytWpOf5WL2DimNu+JBYj2EpV6SnjYKTxEiP9A7oQXou532JN2bR
FGv3zpSs14/l4VjBoz8Mwfw+w6QfYPnGIb12VobEnCncU56lWiZIaTfSm+U4yyDplfkmzHrj
FfgpWK/fZSTufQcYp85vsovIjwV9KpZVc3/aVkdVvSg4u4j1QL1S6/EcwPEH4fkHqiEbQXoo
N46Lngp6D/QfbGh7WVahmNNdJsu4FnRNoz64ckFf6yvnWwa9a7C9xty7ObLMP4gBPU3GXk0H
en9Fn0K68Vf0h+C6mUdFLwV9KtD7K3q6ErceUy8WR5srhfTswPEOQE/cV6CffTYNFrpO+nrQ
25uOtUp6oeGYEevJfQOZvs/I9J52Mzw8FE16yqf31/PUnDWkD7RkXdDLZnBY6t1jzUrNEMv9
pGf+99KvJKzj26W8+TfJN09GlGKjW7NMenrBqelxCyJNlraUk5b1saCfYTNCmQ3Hqh9FHufK
nYQ+Y1AP0KOq57oeCs4d0B+Y74EPPkqijyrp/y1A75krRaJ3SP9BW9e7vgVUFVzUVyzopatv
TsNjg/l7m8ybyEwJyNOJUOi5pD+bFvSK9KLRp0hA8Ntu5ijdKH8lfS3uxSZEmhnxxrbd7KdL
dE1xfh0yD6pMQf943FsYS7ifgnHeBj11Y6tc7cZpxyrphuR47sD6BqcQY9xXCCvphzngTFaE
Syq9jMfKfCyX9L40S2t3LLdk7Wx6m/Q8OBVP+rwU7xzapo8oOngJt0J0/LBDPssndyXA0jNb
UvINLSOxST8yKHtkIxuyc6zr4yt6rpvLbThW/TQyaA/va23dANZDwQHeUdWjqBe1nl5o/KSn
p+cT6sW2hbjoo7UbCPEm/4CHagOgh83+xlPfb/0Vy8MKvWG1XCt4Zfs1g/n+JtNvz/1QU36x
KnqvpJ8n6FNEmnGbN9iNlaSbxGYsB1jaGj1fDc35dVDlPYmeBmOf8eZYOeOIMXNAj27ssAt6
stLb7VjJMAvDPKgPQ07fWIh2MxxO+jGB5WiRhqOiSe9vyWrQTxjbjd91Y6v0qO0Z6zQ8ZUBP
Vf4Iv6RJb0cXG+j3Qb5RBnrLVU+KPSs5gvoBGp0aMKSPasjOqbCPBj1/Gi6bl0QPWPAnvc86
+VfXr59ubdugUU+kb2+ksh6qzSc9RzZvPoKSPhr04So9SfQ66IbzD4Kgh1J/591rrn7TdH/B
N6osP0Flgt6XU3lrVF/7Wc9n073/6pWD30CdT67oMRlruW7SLJmi7MotHGKZeCyDZaq1I1Gg
P0AVfZLpRmIQAuZKA3rU8Dq5EoX9EAn2HuihyXNv1oj00HJGfaBHj9Vrx1ZpOyVY6InzXmE/
ir6rcdMr8UaWjzg1vdTzvFVwkJuwpMS7pLdK+lEmvdWS1aRn2YYSi8VHHyXeAPDkqCf5RpFe
1fgK9L38Yijpe+Gz5JFYVnD0IdJzn1aRnmp5/FNMliETsnN34oRLPPrzjPBz+VBZ4uf5/52/
ub0nESrcSgqOVPWAfCN1YMF5YP7zzzf3NLZTAELQRR/djmWJHln0Kv+gTjhvq/SqKfvP7qBN
d2UisRJvVa2ssdEnZ5qw602fPXcYbkrYaL7RnI/vxjKxtesmPehTkX4hoLdmY0miT1gjKBEI
voqef6/XoH8MI73Xi32MmJtZF/TstjQivXRjHd8NtWNl0dS0V8xPwT4fTLGETE8GGy3T2yq9
S3rC/ARTkhIPNOmd4BtLpYfphuMsTUtWh1jS2FGfhFiyxdJMTDHynUR6YbnivBLo5SUq32NI
D6FeY90jPQ/JSnOWSnqOQNCkj2/I+pmfUrT3fRgPgu4oT9A/f8q/b3z0cM++C4L6UyTMV0tV
34hy/vPPP3/1882fNJ6gMPpw0od2Y1mix0ityT8IBz30G39T9mYl2m8qEPRj7izErZI8xGst
af7wF/sffHNpjqCXAISUIQjH4JJMxXm7G8sVfVJIcWRFnybphkQbJ77yHfo526RBj17smCfR
r+Fkeq+ihybvgp5E+mlfST8h7djpKfyDTmm4SiJvAimWLN4gxUy56V3QOzX9EMcf2PGVVNO7
EWemHUvuSm7JmjhLDivGrimEFetdUxxd7NT0zpapfD83XQXtotkbvZ5uFJX8KrnYp9b3jRDp
7YIe/9ZxCEx6Vufv38W/2E4fMSEbK+lE8j78o4p0H98uU9A/Z5H18Jlt1FQ9fV2hHmU9yfPM
+VdfffW9zzc3cjdWzcumSTZzJHqj3AQqegzKHm//la+ot23Y5Xrd5vh9VRzo/eW8moR94kVR
d7+z+8Hu3Q++OXgFbdYUFb3aL7U2Beg3mo2xLN2kIr1d0aOlSqb4pAwE7+0mkh7myhQBCKak
N+JNQKK3erFqeawhPSXQ8wtau6nnLVPuzBQxvb6qKKZ5xBwA8/DSk5cykGKJV9AGQe2m95Ge
oix7uSM7xHH0otroQ0W7o97Y4s3oqNOSJc5zjky/tz2WdRzHfBNCeuY7QX3Q8lry7WJxJ7Ql
yzU9WrLO8Ujfp0B/f0TJ9Skassk6/kz8u7CDdo5gWL53Z8huPbMNwTY0CQvvvK7q2z/ZTJjH
QUnfjpJebR30cz5MpL/e6kr0H2jpxnJYak99a91Rn9Oy8uw3lQb6AbeLXpPnB2zfDl3lwzT/
x910qKK/mhL0lEa/NgXoD/5mq14NjsqZZP1Ehd7y3SA1IU2kmV3RWwvCUwUgiIRvi/T0Q9Zg
JHr4KfWeKRT2GIwtQMgxoJ/t7y/YoJ99hlnZIR/oqR1L+QY4E1NMeQJ9aIoleSxpDlbJ9D7Q
D08o7w2eDEi1KbLxxhy/Tu+CfpQj6nVw8USBa2C9JZyD6TkIoTd0QFaQr5R5dtk4nnq+bfzq
EKFeIs4CNT2PTvG0bB9V9PR/In38hGwy4PV7JICefybKVKR//vx/oJ/N3J+cod1Se1isZwvO
zg60Ynu4oCfQUztWzctKCk7CjvBXLBe9HosNFemF9tW/8hzX/DNRaek3FQb69a46L+V83gxH
QZoXzHNFf/UKO+iTu7ECeqPRR4v0R9+4IjW9WiSYBvRWRT9v0JO7cm/SHsGw0VjJP+BEMzoQ
5S2JnhIQKLBYH1o14oKeAyx9Bsu8KnSxiEoWCjLpgymWUuBPEfuUTO8nfYFretLxBwfHlMPS
Jb29STaE9DODItTnOd2rgMJeH016OwrBLemV+4Z4bgk3RqePEurJTY+Qs3D1ht31NBbLnVgs
lQXpqXWbnugR75kAehbpy3fFxmX69rrPnTtzDrBHWU99WRmJbeyhkv51kH7zEZ6ZknDLoIAT
VOmjJPoQ7Uaasu/74m82VZZSX1Ggf+LOP9TwoveSWSqTgzSvMC+gR+x8etB7nI8E/dr/dH7u
Fb0f9EnCTUhFzwEIaaUbZzSW8w/Om14sWOdJ9Bx1w9H06hDoZVW40W583diqSSXZoJiXjqwG
feiicF4hC/YpN70f9ENEej6j7nis0N7nsvSBfpSCi2dmEGc50Uuc75W9gp54UygMoKa3Muqd
fizPxrJAE+C8dGSF9IE8BI4sZvnGp97oiDPKRYDpxiM93PQLJn0C6DkFoUyd9PQjyj+2Wwn0
QL1WcOrqOqp39Rwx2k1jIyUZczIC1pP4qvog6CmLXi+X4oji66oZG0l6f1F/a2b55Kul/0qV
BPqi04WVnMqSyS7K/XD3Hz3O7/7mrK+ijwlBQEW/0VJuIkG/9/lfq4IeFf3GY3OUbmhhbIq5
WAf0xnZDW0eSQ4o9241Ku2H11ig3IPuQBXqY6if9oJfUYuO7sUE/PVxQDOwtmvwbA/rQReEc
hWDEGz/oJ9lkieeBIWtoykq48ak3AdL3kzCfF3k+r7w3Dun95ht/TS+ktwV6z3oD1LPf3hXq
KccS8IeAE0l6Ij5+RaFOrHhwIOkvtKRPAD076buXHibz/Qp3Wbz56IyQXqMe+cQo6UW7YYcl
5+BwuOWG1g9c1AdBj8VUtoseWZgJoKei3t1Jkns63xtUhh9XQaB3Z6Rq+nC1Rz3Mv2NqeSXd
APRORZ8EequijyL9h8+fHzDSDYVXppFurATLuYNeN2PxDJG8R1Ap9JZIL2vBDeixIrZKFsfy
wYtTCaDnAEvWbsaRVs/2Q9jcg8lm01X+YHrTmp0imV7EG5f0kyzS9/VNuOOxkTp9APRoyWp/
CmSbMNL7WrIB0EdU9OrXFkkudkjPBT2V+yGk55j6GT04O4jBKbLeoLQn8UZltc2T+Amg/1+4
AqIfiDI95+n7u6hKemj1LOBQQDG1Y98D5j+nmSlKPAPqObLej3o/6a9j6Qivi6XlUpx/kEz6
1g3Vv3eV+goyWlYM6AecLDpeFlgy01Ew2vjPg/QVPRIQ3Io+CvT//Pz5b0SiNxp9CtRr7Yaa
sZRdifiEpBOYjaU9gmnmYv1OepboDegnIdFboKeoGya+Jd2oPSRau1EjU2Z7eBEBx86iKU+7
obhKlVzp+m+GAXNZN+UE3lClL2fMyUEIeG9MXnEI6RXoS2Z9rK3SQ6iPJb2KoA/RbjTp/XkI
qqAX0t/zqzd95LycoUwEvlnGZInJWXRmdS7nfFifVNGzNnK+TClP3xbz9Udc0hPnuS+LreBI
k4dKD8xDokewGaMeAo6Fet2XDYDeuOgRUUz5B9eTQU9K/dHLjizQYEYty/jipfrWKgX0651B
ZlLnbcx/8Ufdg/U0+rNw3Zy1BqZi0m6clOJoI/1GtG++FNDLxlhhfuIxKn1K0Nv+S715JFUY
vZ6bNbabl+jny7jo1yGkWK8IJ75P+UC/hmzzAn2t3dDIFLyUcsbGRbFBSR9MNquqoi5tmMVy
nOIqJ9ySflJhHnkHpOx4gTe28QbIJ5elnqIyQ1NjJqh4YpBJT0J9eEnvN984Y1NUrw+wo17P
TnnuG1XHc3qxV9NTQa/fEkZ6qunN9BR5bsh684TFG8lHWJrzP/NUUksqIKzMO43y9hurpEdR
v6+tbmcXWek5AgHCDU1Qqap+J6p6SPW8nCR0OJZ6sZZEj2j7dKDf0P5bx1PvTVuuzIVZtK9a
GaC/73Rhc0i26TUt2O53/vjHP+4Pgv7gJbhuvF5sXKxZyor+d7hX/hsD+mMs3aQgveE8bQZP
V9EHkool0ixNAAKNTNE7spPeddE/xlopxFga6QYeHAm+0d1YaPA+0NPIlJxRRXmAPiTZDL4b
3jUSWBROFstx0mjYY6ljEDTmhyZFp7dI7wYUc0c2QHoNerjpGfS9MN8ESK/XSznJNxbodTY9
k37AMViKRuW1ZPUmWQqlN5ZLrunFUekdRXp5BflvxGRpSL9UrC9zkf75cx5mP8CkVyU9tgjW
3QGre44g0wyAP4FgBI16jM4y6ts+MGK9W9IHXPQE+mSVHiX9qZ0vu+k3NSOLBtuV/EQVAXrZ
SqZPQ9XzkR26wCfM76c/Ae0GoL86F9Ana/Tc/f3p3Ct6PRyLudhUoHcmqmTzyFYk3aRINLNU
eiY911F2otmwXdEjm15c9Rr0UOQV6Lmkfzata/lRL8iMSnr46Id1O9bTbqpoj2BoST9FFkrK
pmfQy1AsVscOIZt+cpJmqnojS3rOvdHx9Fq7USU9h9MPYCR2ps8ivU+8EfON2SDrJtPzDpJ4
0lstWfbQe+V9qHpDwo3p0+KF+zNEehJvpKZfmrJ+kH9AVpIzSV+7lr7D7u+kG8uH1oLztlhU
8+28eEqSLVHbg/rQ6gn1VNbTxkF/VjEEfkuiF+UmLei73vsbZxine03SN78a3l4JoHeD528+
qTVTsJiOUpwPqejJdWNX9NHaTcqK/pd0h3/IRbxaO5KqolechzQv2ZUpNHp/gGW6xeDaSC95
NwR67sUaFz00+XrZES7HC75RpAfXDejrjS7fP+7Lu6kPWzSFkj5yaorFm16S6QnzRH2y2lC4
GfVhqd4v2WnFblFPONd+elul55EpCiwmdyUM9VHiTaHAeQg6+UaRXgZi1TJZSq+UPAT7aKSb
liwtCbdnqBj8/preC77BzaK8M7LTU8DljCH9EpT1rIGX9bI8DlM+5JX00Og3yFpwXi8Fsw3n
nVEGDr3GQn1r6wcB0423Lha/CSiJPhXo2avzybvunsFyXMQ41yeX1Q/6J46m1n2+1nikgPn9
XM2HVfQPUNC7FX0k6N1NguFpN4D7Vr72v+etUeirploZy/q90m4I9Kjo6cXY4+4alIqe52Lx
hnTiDY3tfnG4W37rMYlmPC5lgx7GcjU+pUCPQHpeRDJbT05KI9qA824MgrNoyirpx6JK+nEq
20mmnyrScnBgvigplpKAgFeMGoelT6V3dHqrpJdynkQc9tGjpk8gvc5DYLgT+zXnUdNT0zVS
vdER9cR1123JpPeJN8p7o14rWwfhwLHEm6Uo7Bmj5TsyRT84VEVbJT2UGzRjabtUO8p3XhhO
M1SqqEdZ76Ceqnr7KNDr5EoS81OV9Gqctud1X0/WWlo0V8KWyfuvetC7ss2t/+G8/rWr+4co
5nEiSP8AXpqUFb0Fejw5yOG63Qjw/I83+C6tBeHZwEiwVn1YTXIiuKK4sxZccz0l6O2nAcg4
DPr041JbDr5z2O5cm3GpdTQuZYFeRd1Y2g1ar1OzFGSjTnH6mQqwdEHvLJqyQB81NQXAE8yL
40NktUTOmcK8gH5yiOBPCQh6AYlPp6eOrOwKN6DnrBu9f2Sin0kfDXox36g8BBmVIjmH90zJ
YYEmqqTvlYWy2lpp+S3DdHrWbvQGKsL+3T7jsdTqzaIrOH38lF4mzAn/Nng+disZb0S5IYle
1sXCZkPzsBSCw0U9pHpU9S7quS1rDkn0HboXC3Nl63W4K9NoNxxtjMTLI+997PZkZ8v62qX4
5lY76PnhoU/uWr2+e3I//IIoHwP6S2uTK3qVY0YlOt776kGnu6oxLiX4lmNH5XK/AU2E17J6
60EIxbwGKj6wjEw3863oU4F+7X5dxlsXzUj0jwv5Ir+glBuMT/kqelC9AJ2eT364nnR6tWXK
B3pONvOp9DwGG17So5Qnj2WfTML2F0moV0dIT682pPdhXuXT26SXnGIvvpLVm75ShPGGQ4q9
jDPNeaXbKNLzHGwk6cWIee9eYMkg099QnW4GT8hapOf0eurH4tcBS7xZXLV+sI+e2styQ7jH
KLek3wOZvYNBT9pLG9lmJBjBSPUxqH/FL9EL55PEm1aM094B6D/Baff1ZL3VRSmoWobvsrpB
X+toaQ3rtfkGU7C7FefjKvqrlyI1ekI8bYvFvliai/UWfTPVVT1OfNdqydYt6te788R5EFt7
YGjNh/eSs92JM4NNACXq8jQhxRv5dwUnwNILQIjUbjaC8fZzovfk6PViCxiXskiPtYKjOvmG
9Zqqgl7FMVr1TDvpAf4pSDc+0gPopj9rl/Qwq4QE05PhhmHOmB/mjqwNemW9iSzppSNLNT2X
9BNkxRkgq405VNNT2E3Y1JTE0VNa/SAL9aqe901P+dKKhfle8S6kd8dkOSjBr95QN5b89Fq7
J/CPwGGPwGLlsbTL+kWQ6+XT8expGfLH+pbW02Nyr2rHPtwHGz0V5dg0JfnEEm1J+o1U9ajp
UdS7As4rqqYX5WYXKzeUf6AwnwR6cF6N08K2v2vzdqcnW/OkvC9fwne3qkHvRlW2aKtN7vCD
3X9MBH1MRe+lzouGfoxLcaOlHyPKasIbnv9UXemfcz1vTy/xK7xzSB/f62kZoHpGiNfo/ZxH
Q0ACECIwf+WHSo63Sd996yYLt95c7HhBerG6pNcJCGS7eVYFCw7VujhD088sJz1GpsYCIj1Z
6c2iKRv0ZLEcDzpvwHmp5nsF8wHSk9+S8ytleWzgGO8NOC+yTd7CPO0iIdLH1fSSfEOkZ92G
/TbOSUP6IOgDpGeuW84bnpQd4C1UNCAbfuZpr/c+2QD/psvZT2V7aomrhxXoSbk5Ra1XJNx0
nGqTjSOEel5NQlW9oJ5Zrx04iDsTAYdBf8Isl9ISfXrQ8zNE9ceOa7tbLbYo2wsY+42tZtDX
21JzzuyCPfwS9gN6oNclfSACATq7XdGb7eBcxLPqjriajceAeQV6q0kK1h8Tbca0P5F/IOeA
SgJ2G6NK0OEngcA5QPuh6NDzA5f5/B8Re/z59GEVPX0sv7+P9VffCWF8Q8uO9f34Rkfph/+m
qehHCwXuxVqgH2eBvgpdWm1GyTPlrZmpcJGe1HiJNXOSzaqq4LzMB0GvtHmKQggE3siG8BJJ
99ElPdf07KenLDMcu5xn5HOymSZ9wGJJlTxvDs9HcV7p9N4GEremZ2kndMGgr6bnYl7KeHWo
xmfQw9oTRfo5i/b+JwzOBynn2Vg8Hvl7/BNR6Um5EYn+RHUHCvo9ex4+5LgzlVcPVecE9gQS
6cmCY6GeqnpHotfmyhTajYk2JtDvPHXqfacnmyvz61epoHdclQ06AaH7pS/+CNBr4SamGXtl
rUzGfkMZloT5SwcPXlGIJ8B7h0HvH3DlN9N7YTJq49pja3+lr/NvdDMWr6Q/9FzB7ynafWh1
D8Qr0uNJQJ4J8EuBJQCpZw0S+0NBL+ulbMxvfCko1qCMb64324/5B2u7ia4sFEbNvwnwqOir
ZqexN1ad0WGMypYkvtIr6dWWKb92A6CbZDO7pCf13rc+dhxbSriaJ5V+KoL0/FQwEV3S84ws
1JtRVc6PeeOxqrSnmj6e9GyzlD5soJ7nX2fChmRVES+pOME0S63eDIpplBFPf9syvZTzjPoB
tVg2orJPwfuIjyzyk3p5F6N3qXD7SiIsodwA9DBXsj0Sy2LBeUG9XjhIRb1T1ZtghOu8LlaC
bk5IFn0a7aYV41KyffAIaT5IyKnbcOL3Tk92Fe8jWbUV/X0nfshYbd754gsBve7FRpH+Abw0
WA7+4JtvAPpLZ69cBeOVjcbzNxKgEULJmDZ+G5f4aqfU1bX/k/4pOooPoIWA1vsFVHVDZOG5
lPhU0QvmgX1V9Svcy7ODqvRZNzKFPv61FfNSh2RhrHzitS8FCvncrabLsoXFHL6CVi+2MGWB
fs0skm/MKY7Xg/BQ7fO6oDdRxTBaUq6ZT6QnjSasog9MTY1Tg5Y2Ck6yTF+MKunJXq9S6UPF
mzFWb1Q5T0q9K9341ZvQmp5Jz1p9+JFh2TA7Pb+BTZhR6s2AkF78lAJ8Y7E3pEfmDb1tKQ7d
12W7TlA9JKnjlnuNpmPZXImYYsom7oBrRoPe2kJ1ZyfrN0rAAfS9DJwNItED9EqiR8R9mm4s
SfRsupFniFMb8Ik+dtqAt1dtdPFqBX3ebi3mlIaT++FL4PwX4PyDP8aD/sGD3ZiXWov4SpTx
qONR3VtcRhWuMA2M0zMAJ1HGnis/Mfz8f9G8VPyCqY1rTQvWaucC8CTwCPdBbiXn6L+ovmfl
R4UYeGAH6PcS6JnyQcjnGlqaw+5nenb0MorrCwUt0a+pnxq1IF81u0YNx6KqNaDXpJ/EJtkg
6MlKH9qOJVHHCkJgzGMZFcdXkk6vNXp/P5YbsoNKpg9R6cVPz6ZKZ32sxXveM6U6sqGgF/MN
jcnGkT4QWyybBeG4iVVvKL2YK3nRbEiwMQ1ZnYGDfqwq/Beb9QM8BF3eFf1z/rXjAFX0Srnp
Es/NBlFuTFG/7/oHbWTAcVDPbVmp6nlpCQGbBRjeNJuK9KYXq58hQPoN722yFeLu8TK/hlHf
3ioFPXfo9dGYP/zSFwb0u2NBT3ING+G5kA/Mr3KVTkd1ZclkYy2YCo01e9O7wnsV6M0C2YDq
w5/Q+58U/MR3z6qjxXw/7VnJZ2HHWHnAfpVduTYgyXfXXNt+N+LOdwMQhguF2XVe21VQNzQ9
q8yWLNcAgAHQQ7spUDfWV9KD4IXQkt5aHztO/8YZo8AbGpeilqsW6X3GG069GdQmyzDSi2oz
MOoLQrBIz5umlE4fU9KToT6C9OERZ7J1ECdBvQHqPbwT3LVML55L8tTf9SZpF5X1ffw7b7lD
ivTXdyDS01isSPTw3EC5ue5xHjW92i1LXVlBPXdlla8eqD/FnJeIYoAeyk160LPio+esNnxA
pO/60nHfqCXU5X4p/d/f6gQ970bzne6XmPKqoo8BPbbFkha/FvI54fzK2iuSPiYVu7cCXNyV
TPUUoP+9d2U/ZNDzQFWqDAT285CED35rkYfLdS3pWLX93r17f4T/i7CjdB3U/pDoN/rlGhJr
qOcade7TBdRzsY/XgG4YWPIOAhBUppmXdwPrjcoptnw3kDJCQB/ZjjVTU+OUfWPqeyY9Ve1j
saTvlZo+BPRitqE0hGBcsYY96/TRNT0Zb/ToVBTpKQ7BV9OLH4dPfEdWQK/pbltvmPQjsF2K
eGPOosCepSI2kJT7gCd1jXKfnjvzUJQbKuhPwHPjKTcs02vUQ1gR1Cv9hpLPuC1Lr0I9j1Ul
LNGzEydNSY9EM5LoGfQs0TPoN2z42JGJW1bljsHVCPq7TvS88D7H1bygfj8arBbobdvNgweX
FOWlygbwuai/cvDKlYOXrpyFloPDdDcuHLwYBL0/kn6Lde//ypNuUqKeq3viOrk4GftWX1X8
OlrGB+WtQ7ZK5JkdOOYMu+Jy1FyrT6o5ttN1u0YeGwy70r5sXciWhqrIWwOvjbUpnMUbyPY6
7MYjPUT6KqrofSU9UolD27E8NTVVNSy7ZfM6op5Bz7vChyKMN2S9GRxU1hs/6VU5D9KXQuKK
HT+9Ir0p6dVNV7qNdGRjanoagx1xMm9sukeSnoJwBnppnayhOBXxTk0PpyWZ6W3Sp5Xso+w6
5nPx78DlbhvJs3ZzTo/FwlDTxcrNPiPcGNKjK/sBzcoS6o1Uj6oevwIg+gxlOWdeios+LehF
oifOK4legX7D+xyuqU9DuT9fhv3kr0LQ9wYnf7ANVkFeVfQ26E3WjVAecryYJ6meP3jJAnpU
UnEK0F/5sXVx71N1jmZspHTjl3LEoY95KQa9KvCdoSgOVVCwZ7aD7uoc2PKSe0Gg1iRCnr5b
/rVoHKZK60xMTq/RMQgAvdZtdAzCOIw42nVjQunhpGeR3gf6Sasda+2OhbcSb1CjRoUpY7UU
0NOAbK+R6d2pKc5CGBwshZT0Y6LP59lbORFT0suecFFvfOKN6POQ55NIL9tGPNSTQO9lmXnV
va8tS6Sfof8r/400ZGc0ibWd3hZv5lDah4De93xB93aZ226ePxftRkn0FGAWUG50Sc/6jUK9
1ZWlvDOu5o8c2XzkE/D6VFtPWtAHJXqMysrpOW//jHWXdTxceIG3+kA/7qwY4WfZ7neMbONV
9JZIzxb6B2cvMeeh1aigeNTxZ2G6IYslyncakvWqePtfKUB/lTZamfO7Y7oZm7KipzJegV6k
+8DElGfKF3X+EAUTI/fgK7eUB+RTd4vYOKZDGwn2VcJ4baWHTqMHYzXokW857IFetWOnkYcQ
Anriucmotx2WXNLTGXVGp4T0JN6MRpb0Q+RIkU3hdkkvQZW9o1Bt2EMfrdKPjlodWYf0bKvk
DEsmfZxOL5K8Jj0H3VhDslGkZz+93jQoEGa4W0oO8nIC4o2L60gpxwa9j/DqRbq3byX9lrfS
byfLdO5TGYsl5WYXPDeeudK0Y0W+8VAv+o3S6tsJ85s/xx9SYE5t+Lkaoko03hgXvWj7UG4M
6Dfc+ZUjI2xf6Qs156+/6kDP6yWdk3sHso1N+j+ict8NBUeOGpQC59ldQ0rNlYOo5CHYQJ8R
zusTCfpjcFd66n1IN/b/YF/5N70FU6lEeqXWcEXPBX1sfqUx4h9zjfLdNc3/37nc/zwVD/P8
UNUzAL3KjEtp0KOiNztIFOkB+qIx0uuSnpz0LNIHk83C2rFTsNh70rw3PCWg5w2yFHYTMh6L
uakikZ5leg/0o5x4AMmGDks4Mf3YKNKzYjOo9CtV00fI9Pl+O/jGG5jVFXyseqMD6z3SayxT
c3YART4smn7xJozcPuQnfszgKki7ef68QD/ZPyKJHv1U5bmhsVhbulEqvY16LdUL6sF5rB/E
OfIJ1gh2PO+RadkE0APqWqKXPbPIuvdIjyWDjs+yvJNAQzCw2kDviGX0qMiR14aO6sSSjx5Q
N6BXxfxZqPCMeEjxlzAndZb2jpCPPkUifYqK/pBzaX+JCSu1SXB+oI9NKuZ4TF/rFZr88Fwg
T+/LP/mmhJ90QQ/lnlKLbdKjlMcMVSlQ0c9iLXiYSE+zUdgg60zHmmo+ZH2sJd5Egj6E9HlR
bfTm2AmH9AEzPV7B6k3eFW94KlbFV3o1fSTpLbpb1nqb9D7dhl/sI/XGBBkzvbWtHv9ki+Xg
DFR6tx8bXp/7X5v83LAK0m7woCSDy7E9F3gs1lNuIkEvBhwl1auuLJXzn7+KQyV99c73n3/s
gj5q0ZSr3JCLnjivxRv4LJttLaGcFzOufo2+1gmf0KoNcz4M9Ax56DHslacq/tKli/j/A5mH
vYIa3Qf6cO0GoE+o6A/+xr225GlPr9GzZ19LN1ZgWkTiDar+HzryVcPN9WbaNT3t79Ll88Lo
JwoFT7jhGARY6UNAn7cqeqXdDGmRPphsNuSAXvtsqKYPBiEI6BPEm8lRlLL9nniDF5Vqo0t8
dt+Ymj6S9Oy9UeJNwcg29n5BdGSTSU+cN0n1SaQfdJOMCdaUbybQZtBTDI4x06dDvLxXIugl
7Sb9w2OF3pN+wA+fxFgsJ1d2Ve/stKalPCu90m6kqkeupd2VpXqeOA/SH2k8sfPd5z9Hxk2K
kj4g0TPnW5VKzz5LW6i/tbpCzlZVRX/Pb7dBOW+OXdFDumHNBhoO6A7MY/QVhL9EQryWcr7B
xFRK0MNeeewqpqsc8caZn/rS/bl4wwF9ur2xpNHzfqlQjd6D/lVHlUcpP8+sJTbd7DAVvRWA
oLQb+CvtZixtFERFHwJ6HXcTYqW3w4q1NI9xKZqb1XYbv3jDY1OTUdoNFk6B9NyQpbBKniJF
+9U+VOL3xsn0UtN7pNdtWKsprTuyUaSXgPreflkObhqzCaT3RHr1jrilxnoj47Es3syjpE8E
fR/33st+sJOC9nJnlLkSDpqOuoBy47VjNe4dA057I4P+dSnpd1X/i+fP73xApE/SbuygGzFX
+kC/4c67diBCQ3lnxPmeqVcT6Pv8dhtY58NAvxtIB8/JZEMHSvwlara6qWYPvklf0Yf46CX5
TG8h+el/ci/r3/+UF0zNyXbjgT7EdqM5f8Wh/PxKefWtsgjmbR0pFCYN9PkftHfED3qKqPcm
ppJEettKz9EHOBMSdIOavj+QbaZKehqb6o0WbybzYDun3hTpX4ODBZ/VcoxIr8djg0kIVON7
HVnU9NyGnXHMR15AfSTpZZOsNGKtowge2pFV7VhluZf39PLNAHpqzkLNuXfXeHHmUtQnvO96
ur/LvonYyyI9lJsOy3PjKjdB0FNVbww4WCfOFT1I//nmnsbNeLi/v6H1g1deiSd9iEQfAD0c
9bak0D20Qr/2zOfLriLQT/rsNgg8CAM9SvlLsNOgdmfMn6WESmI8XJY26h98c3AtCn1Xo4+Q
bq7KbFV4Rb/3w1+F/BL3746+cUhzfq4VfRToL9mUz9U0j87nDjcfww/Zp1ak2XgQ9I50Q056
GqKyRHrRbvTykUA7FnAf5fhKslpKA3Yau2NxqKQfiiK9PTalHZaya0rWkBDdx4aKVNpDxgnO
TnHsTSF6bMolvWrDaje9Bn66mt41WloR9WGkR0HPe6jcfYNksiTrDYEeuQjzFm+SnhMYoeW/
PoNE+kPHaS04JHpKKHampfy+GyPhkNcSA1R1yLBvbNxMFT2X9Ec+eRkP+Hepr4qqPrYdG1Ru
giX9BtdRn1u/oJ/AZf3g1QN6rkis45Tznki/f/f+B9RxZdBrpUZtCPeBHuhOC3oIKj7XDVX0
V7a+sf5/H313/WHT70SoTzii0cveESXdBG03+x3Kt5yfhyrvfqcsgxnQzxYK0y7oHwPqLuhB
euj2QdDPjkWI9ITzaWwRV8X8FDCvQE8lfW8U6MdpHbgem/J76cl6Q4Cn4SnyWoaFIaQlPTqy
pT5pw6KyD6vp0Z+NrunJQB9cJRtZ05NC39c7wINT9hmATg/lBRr9DCckDNCyqSRsz+PtdH+X
fwuRhlC/IomePTcdbs5NuEiv/TeQ6mVDVA9r9FLSv4VH/b88xRYaL8TyFX0+8I4DeuO5sRyW
ylHvRN+sHvPNqgE9Z+p6B55K/5Gp2N27yTnJ2o0ca52gA3oSX+ZS0bvuyoMHN/540x8Sn5Nr
//nDnyaTXnqxvDFWrzdxSe8oNt0t8+m9Br5VdmE81aSfNpFmBvcgnGOvJJEeGQkO6KWkx9Lw
vBgsg0vCR9VsFKZt1WG+T3F97z+WeNOvxqZCSnpuyIaqNpr6bKcvRYWbcYNWvDelGdos1S9N
2TmqNyze2JNTWsFRFht6o31IocfLNDTlzVfRO/BrBPScYnx3Pv3YZJGefnjK3kj/nBTFw21Y
LdIlY7Eqit7xV9oGS68tS/1WdGV3Vjf2UEkvvpsjf0UP/B5knW2AfhNX0nO4jgq6sSR623fD
qK9ebyvIZT+Cpn/uVwno/XYbCrYJgp76r1Brrly5An8lJBz+X8Ta2AcHLyGm2F/Rh2o3shzc
Bv2Vn374D6kTL/7Tl785EF/TU0kvCQimGWuBfu07lmbVfXN96i8c/zTEkWYG9Bxp5p4g6LGD
JJ8ft6UbAT1GppSTPmilF2V+HD5LB/SBuGJmvgK947wJK+l7GfO9oSGWnp1eD06FOW8U6Yn2
I3k9OeUjPYv3kd4b4Xx60ktBj0MmS5f09JpeSDeQ5knAAe19kTfzqN8DH7I6jPTPaQl0jqLo
d7V3VdMSwX17trmUl1z6sEOkp5L+kyMC+s8/3/w6/xC8DHLbRX1oRe+46NGKJcuN/N89dU7I
Wc0i/Tgm1owLfIfVAfpaJ/7/e2z+xnFBz8W86b9eBOgTgorPUkV/kCKN7RM2MnXwKi0XMaA/
8Jsv/99zver/7eU3KOUs+khFL6C3Nfq1+636ofvmurl+4cj3Z3dlwzpd0Y/53JXwV0aAvhgE
fbhIbzzzQ7JrygV9bEnPzhs1NhUo6YsTotrQasFI1Dt2+lDST3BHlhYMhkcW6xlZDMuGqTf9
LNxEkJ5/izGZllLWq4Je/uXW+iTcz4zIFnESb6gf62wUXwzQc35lma+NxaN1iB6XJ6mgJ+WG
ougfpgY9NWU3kEpPJT1NTG0+8i7/APy8muLlUdRTVzZ8SXhQoteY94N+w4ajdshZw+qwWa4K
0D9xbZXdtF3EqehFtFEuG0q0gXJjRmPDS3oMVWHDVNqKHksFeVv4lh+f/9/Nl7X/9c2fBNZU
Cfm9ip6jbjzS2+3XhqbH8/3KYR83TT9QNU91SV8olHwFfYhG/5j8lRMO6LmkfzaBTbIi3eiS
vgox9QK4MW2l95HeiisOOCw580ZH07sl/RCtjxXSx4G+yHb65IbsTB+CbyJJzzV9KOmF8/1c
1vvXC5qerN2RHUDZruv4gEyv/Dik3cN5c3eQVPpkLWZu+O+lYqn8QV9Lv2n+pOMEQI94eVJu
tm1LT/p9r6Ckx7JYmpn6fDPSbn7Oj/2/oljLnZxVL03ZYEkfkOg/MKC3rPSqtn/fnpJtKHvP
Kl2C1QD6u04eNHnnv9jvgB4vkm0eqs03kObxL1htAPr4SPqzZ7Ez1j8wFSHdYBPJ2oNrf/Lm
0AJRe/9XH+6NqOqd8EpOu7HHonI3F5XyuBn0K/L3Tes80I/5QE8OG18zltcL5oOgn0WuWckS
6acneYs4pqKI5hGgp8HZSJWexZuSm4PAxpsxoVueZfpY0tt2+sixKfHTJ9T0YeqNGCvVekHf
zilvmyzeR1tsbOgT113xhkep7mE3CZaY3Hsyg37s4lssGU4L7uEv8Ccg+cPph31vdRdJ9Dt5
ieCcQA/thhIoewB5YP6THvX13sdeWUG9KuoDpA+66D3S+7QbvHjDbhl29yXfqhV/j1UA+ruO
fZ4CzBj0toOeMP/gIuj+x/1c21MvNhH0kN4RdZNKuqHs+p/+86Kocf/q8qFQ1PPeEU+5WfuF
datrLi/Kl3YebDw/s0lX9I8LhaG0oLdHY1VYsSXSP5seRm4xnyE4bkAuk2w2l5J+KkS8gd9G
kh/zxckhst4gsjhapi/advoA6Sd4WTgfu6T3N2Ql4SxQ06t6niQdnpyKIr2n3tC/vM4sWW9c
0tNrxI3DzwLoz1orSOZWuke9N+9Y9m2TXHH+BL8B+u39AMZiIdHLEsG5gR49VWqp9hxBSnFj
u0j0MFhSThlID/2mjpuyIaBXWfQUdINoZNhxlEIfVOlB+vbLduOsUIbX0fctlT/onTEpMduA
5Qb04rTZvfsiO2yU8waTsQ7o7Uh6bb05i7DiSwHQh5X0tHjkGMr/Yz++/B8Wdo/+/s2fwpEf
B3oVamZ5KRuuLckEHsuM4LyU9HBXVoWA3ue6efyYJqZc2w1rN0akr59C8A0flUWPkp6t9CEq
PT0JYLeU7+h+7KQn3mjtptjPDOsvkpl+qETmyjjSc3axttP7SA+3DU5fibw3A7GkD+3Iim4j
0j2R3oQguMTv7ZXJWerAuh4cCPI+0tNrsI2QxBuy299d3JKePu8auscXr8mzsJ+E6I+mB+Yx
7bnBEkFwPrV2s29fK5LJlHcG26lOiET//Plf07YpS7+hASo52l8Ju45ZLkUh9vx6jfpgSb+h
2s5DyI0t1dVYtM9b9qDvdTY26lgbLd1w2U6Uf7AfkBfO09JYH+glkv6POsmSWX+WdsZy7E1S
Nxag52bsJSShHXrjS98UbNq74h8v/ziuH6sqegL9xcPGRtp9M1W0fNrvwXo/sdFr0HsLY72g
YgSYBUAfmJhSJT2K+Kln9ePQ6oXyJsyMBBrpxQb7sZSJEAl6Fm8mLPFmiGp8zMwS5pn0ZL0Z
i63pKdZSkd4FPXsrZ/KjExO0c6rPDqcP1PQhOr3WbYT0pNPHkh7qDe2l8gp6pzWrXk2FvHoX
bstSSU/1/cKP/rpF/h1uHg+V5f0QUpi+Is/NiQ6t3KQHPZSbUxSSQ5sFYdrZ+dfqe6+FjKNR
z/6bAOmxdMTdIphQ0m/o/NhSlHNlz9Fy/wYnbM7f0nKNVPTKN6/t8l7YzX4CPYHfnBDSU0V/
cHca0GO97BZuxtK5cung3g//nt256c9/OvqbcMHGK+4BeqwGhzLvrRHJ1ZxffMlGf9P8KIVE
LyX9eNBdiWbsaBD0cKBYO6ZYrqeSHiJ9YVRRftQDO6w2wIxJNvNpN2apoEN7XdKzeKPGpoaH
sV2Kj8I8kZ7npopx4o1tp7dJP0iYHyzhVRMlknB650b6ASroVT1PpCdZJrAxXF0MrulH/AW9
CDTuhKwR6UW8QUk/otWdecPeeW7h0dgd6R+0K/SeZKR/B61YKDd1NBY7p4peVs0y5+HZqX7f
3IaPmfRU1QP/pN/Q/JRV0vuz6FWhH1PSbzj1seURyS12D22xr36Zg97ZMtLiBZihfldrA0Wx
AdWt/EoE0ouMEwd6ZN2sPZhKujl7xbZXnqUgzGM/eTN5Wkruq7/6+8gGrK3hSEW/1tNsGq4t
aY+HnkAxL6VAXwy4K8leGazoH2MbibVjSoH+WT0CLOU4lKciHmV7v6nofaSPL+l525Qq6QOY
p5KeGrL5WNJzOr2y0xvSQ7vncp4PRmNVaHFqlyXN0t7ttS2XBPMo0vdT+U/PDC50e6n96kzI
cjtW3gnizQgJONyc9c4ceO/7YvIigb78B3yozXnYm5Z6yKBP6bth5Qa9WEL6jZd/7pRJ/+Ld
13uI9LRHlpuyGvXMdAY9rYvlLHql3MSq9BtOnfrYcn3nyjxGqLxBX280DFCpyQqqFNDTWhH8
33jqdU2Piv5BMuihyATSK8OXTKGi90cgYChr6xvn/13S8+4v3/wJci/THKroj3mazVIW8/xN
M+hNRY+Fgj6JnkLNCggr9h1sjXVBP/tMeWxA+VJVcEu4syR8TiX9+BDIRtumhtlRiWoehb11
hoYKID3izWIasradXpGdgnAwNqu5P1Ei7FOUZTTpHfWGMxOsep7EG1ZmQjuyeCV3ZAOg5ywE
qyErDktR6eG8uUegNyW9n9sRyA/Fu/dK+mGqSXrErvjbqWfc3Q7PDSk3SqJPC3pRbnY1vvfy
H8J+5679+cevKqkeRT3R3Kj0NFGrxmJ5z6yW7qNLemg9O1+2DfXlvZC3rEH/1OJ8w48dm43u
tTLbjaKjSJ8S9NgeG1Buwpqxl1i68WfdUITClb2/+fK/ifrR+Ovzb2xVWwuTWE/e+a0bjc8m
d3PJl1IO0KXFYKwq6TEdFAb6AOcfYzR2ytoai7Xihm9QaEJiEOqRauNZ6X2kHwpT6c18LGfe
TGrMj3FP1iF9snhj2+kZ7Wyvx3JZ70xwYzYF6cVlGcJ5ZbKMJL0smQ0cIr33SrxEUQjyChbs
8b8B15oTC/LEd+2n5/byz0Dgil48N22nlXKTsqTHuFTdnfbX3/qXMc9Wf/XWy5tFv1GjstKP
9faCqy2CTjM2MB2L3wf4I47aaZZl3f8oZ9Cvtzh/629f8tJtvlARNgx5y2hpVPrd/oo+xHaD
PPq1Vy/6e7GhJT2asVtCQC9JxWt/+ubvA1L6vV99eICXkKdNKt540WC+4dq9pS+rhunaNqz7
zwJ6uCv9Nvp1MNhMBEEPI/2YBr3XfO2foFyzWTUz5eYgSLJZtPFmNLofS4HF6oxOKu+NU9Kn
JH2v7CEB3KWcLzitWUN6r6SP7MgWQjkfZ6fXJX0Ih++C5YbdVN8T3414Q6yPLOlDkJ8IerY1
NCz9Q2uBX4E0+pcI9HcQRX9SJPq0oN9w42OZkIo///Ld19uV1ZKKelFuTC+WNHwv6yyypJen
htft0alyjjgrY9DTDgJ9Wvbavvn9Fy9e1Cab0Eh6GOldf2VIM/YBloRfPeuPQIgA/UaA3k0p
9vbGYt/4xv+r+8g6unUr51amBv1+03OuWZ7oU147cktX9GsKhSl/RQ/Qjz4OaDcAfYFBX4/R
V+2Xh2JDBstw0JN2Mxyl0lN+cQD0XklPzhs6o5NTIZE3WqaPFW9sO70sEe+bcC04ExKG4Jgs
o0gfwflY0nMnNqykZ2OmQrbMUIH8Spcnt+XcSvpE0PdTKdGdBMEVfzu7bkygmZLo02k3ne/+
+5Tf/l/9/D2vqNcSPUk3jkQfa6WXp4bG13kgRZ0ybnWXL+htzjcdcni+++LFB2yl9OWaWRV9
hJHeMlg+OAhd5VIq0NMqwY2RoKey3qfP/XjrFjwzOH/idPqXNOZzTctlyOWrSwkIfOCu9IUU
w1qPReC0UdA9z3g0th77ZHn4tX90qh6bSJCCgH/Xh5MeVvp8FOhjjTdatCnRvqmwFEssH6Hd
I7H92GKR7PR5quiDso2S7SfYbpmC9Jxd7/RhTU+WwxBCZXrhfALpqTcL5nu6PXMeccUJurvV
qk18z9UBehJDjpFycweeG8P5VKSHcrPZ14INA/9fv/u6NGWN/+aDOspCY9Dj1ZZEH+Oll27A
J0fet9dYly/pyxb05+0nyq3OHCyGYC/uDoRXKr+leC7PnuWKPtZ2Q6BPV9EfRDP2WFCj95ZM
HXzDeUDVbjWgTyHdfKEx373jbsqCZOHvxmOSLRr0VYXCsxCNnoZlfaCniSmE0rN/PI+0MhmT
hcES2s14OOhdK71PpSdhZypUvNGGyr5eCSwOL+mL5KZPID3Z6fNjSrYxXVhbpuc5WddOH6jp
GfKBPqxnvokiPSn0gzJVFUAx2XUE5dR+xV/kt7HEG6/iT6R4b+JTQj+5Acs/7Ia+y0NdbK68
fvLhGS3dpPDdcKJZV1fj6+9ifWDE+RdvwXvziZjqPf+NUm4E9LxF0N+MDar0dXd2oqD/5Mgn
r9pxCGWr3pQr6G19/toWR7ehqjwc9HpBOGUgJIKeK/pAqFmodHMQk7Eb40B/dYvzuPqHLekr
elPNd18bWTi/U38GLkOaNOingu5Kct34QI9KvopKeT5jGvIK9MikH0Vh70abSSEPSKk52eDQ
FJX0hSDop9R4VB8Nw445oPc5b0im740nPZssKRABu2TDI4vD7PTh6g12lEStIiGYjwRqevLc
4LUcgaBz3qwWrK70deSZZ7qk7GJ8aCK/9SdLfsfVsR6cQ81YoifPTRzo/WHF+z7YwFU2IN54
9N1gR/ZfvXX0E7ydxql8pvq6U3ciJPrIaDOR6An0je9x1aROuZK+TEG/zrtyueZjFudhqESe
DVgfVtF7oEcefaK/kmLmDwabsUHfzcErERW9tTf2lzZiP2TQpxHpjTbfvRwdWOt75B7SNQ36
oaDphkAP6cZU9IA8PPTqFH0xCCjpeUN4OOjJW+O1Y0NKetkja2VYDknYQd/E5BT9S8amIsQb
ctMX4iyWxSKTXiz14aAPtdP7SJ8f4IIeuTdRpCeYDyhJSwNfLRHvZzs9+XJ8pbnWdDTwvbwz
9lvOoaRPBH0/iSK3U5cCK/SO4/TA7FTKzZ4z5+ZQ0mPtCO8OoWmpnafauo6+5Xksa39+tIec
MneQaAONxkI98m/ktcZFf8or6KNVemPTwS8Bm+2tU5dX6MIlfNnyBL3ln89tOuYxXYkxCDmI
Bf0X+y8d9Bnpg7abBwR6uHMCqA9E0h9ERU/STVQ3lkT6N+3r/FNPuom13VzSTpvu5uVOFWRb
GGWasesmxEavNHom/Zr6qQlrQMg/McXaDXVjPdA7xhuq2qciVXoKuXQxT3NU3IIdxpQsZd7k
48QblulHY0nPqTdYGE7mm0jS07isa7J0SM/pZjh9vJ3EHpfy/k2k73NJTyDvY+oz0ukfLuqp
4JdMHHk9PJaWeDOXkj5R3aH7vOx99Gyjr2bl5vS+h3MBPZsrSWlvxLJZxJJhqrbV2OHaL7yC
9eEgPa0XgWpDVDf6zU7NeUB7l0+ijyrpjU3nk8YT1Y3nrQH+5XFTzPXppCxBz8sH5OQuW/U8
c54tlTQwFXLMxNTFgxx+ExuCIBV9StCTdBMD+is/sS78yDFT0XvGm2Az9ooej+puXrqkg6jH
A/8av12DPphGv24d2q7Fxyjpn9mQH5qGdhMCepAeCQjDEdoNloQXPNCHlPSTHumnCPME+jHC
PA6Z6WUHSVhJD+dNosdylER6HEmnjyR90E5vkV44T0U9tJtY0lOv1gg4BHCVg2OFnzlIZusN
RmdNnrFx3khJ7xuPTcR59DuQP6TsQU/PRvt1FP3Dc3MgPSk3bIShgp6En337/q0eX/9XeGHf
dd4frop6D/UncLgRSykJPok+OvDmlPRilU+ncb1F+rKckS1H0Fv5NrlNay37PE3BMt4J4LGg
/0aBPq4bexbsTQt6ct3EVvTHrJL8y7VpNHoddtCwIqqel2kG2IeEFK9bByNl8VmVarxSC3Yc
/prHNDHlLhMUVz3H3ZSeGe3GKelpm5QVgOOumqpCiduvQT8+JpzqL07pzBtrB0mEeDOGkr4v
cjxWlfNkn48nPZssI2p6no0dkdBiDE5Fkp4EGpqa1Uk3thWHSC/FvVPWs3pvmrKymEougog3
6VX6pOeA1QD6Wvol9wBNS9W1XiDlJr12s0+NxTY2nqCGKoF+31FV6Ly1By8A9bQtikQXV7+R
Av/IEejt/KHWyvCoDEv6JF4I2s5TXVZNnyvHiNAyBH3ee3LMNa99SQ9KUX2uDZXE77iSfjc2
wu7+Y4LtBgOva6+mrujxpBAn3Vz9lVc7/4ZAzz76aCe9ttrkri1/NU/fKWeaaYkeNnpfSPHj
Nc8QduBp8lX1egcJ+D+JLeGBo0T6UJWeks2sdmxIST8kG8NpTwlOfmjc89JbMZYRJT0nFucj
xBvxzg+USL3xp974/PRssgwlPTtuBqzlglGklzAE9iQ5cg2/pGV6H+r9EQn4FF4SwiKW9P3U
gC/3ydj19Lg8rgLNSLmJBb3djhXlhip6yC+k3BDou9RP5fvMeaeoZ6meK3KhPG8qoaAbR6KP
KukZ9NSLlYbAqQ3Vlk5fjlmW5Qf6PuuXIOK8Ar3KIFZ1fIJ2s//BQeTTO6APivQIpVx7JcRf
GejGQqNHTPFapBQHDs/G8vnQA/0Bkm4U6C0vvSXemDHYmwNz1doW6f25O2DZ6C13JXlrvJq1
NDw9ay+aQo92NBT0nEnvaTdOSU9yTEg7dloK+TwV/FVVwxOC+cLkuL0ofHwqT0kIseJNf5RM
PyajsPmxIidZmgnZ8C2y2k5vxd6wesOcV+I8V/ZyQoV6ruHFfsrrSaxgBNOY9ZX1sn3Wq8dN
eY+nAIB+JrHNmlTKq7evBtCTcnO4S3JuYK4k0J9L57BUEr0EVwL0xPl9+1RASccFRXrMwbJU
L0U9ay84R47QhtnPjxyxE81ip2PVuJRSbihNodoa/MkteYTJnDFQdqAftDYrXSPOa9A7W6XQ
jo2t6HcfTDbSc0X/DW0UT4ikl8UjqOjjRPq95tL/t2u3xFf0V7U4X7Nyjwd+NtWgn9buysez
VdgSrg9ibepJpXet9EDYmjDSP4NIP0kLZEMclu6iqdA94ZPIxKEzqi04WrqRfmx/yFpBlYaA
sSmR6YNHRqT6JugtZL0ZTCC9zix2ST/IY1LqqpCII8yPWBrukZ4Tim2/ZYD0qjFLH2JlFhvx
Rmr9xdJu+snvXeaum/v0uDyAKHlMS13Ys405n9J3Q8mV1ScoothTbvbtk80j/0Jhnv5i1Ndx
Ra6LeuE81okf+cSKroz10qtxKQv0G05YLstc2e2cKjfQj1ic38F9WNHofWOwMFjG+ysh3YRX
9N5s7DcEerxbGtBTRR8L+qtXTW1+eSP2v8ZU9LvVrywNK9m0cUCPNHr2yHuMLxSKxUJe6Tnp
QD8LJ33hWURJj6LdWzTlgV6V9IrxwPyYNTzlkZ4Wxcb2Y4dIpu/1izeqCVsYk2cAon5vrEw/
yoNTlE5vR1kaV6VcHiK9pn5YTS+DU1TR2wK9kmu83qx5AiAxHq9Wag0/2UG8ka2CAnonzThl
9R72bqsA9MzKz8hF33b9wsNtUtGnIz2SK23lRgr6fZJI/7EFetFvQHrttJRN4q/ifL75k8ag
dBM6HUsuehWZgFFaTj3e0GWTfkkzxudcz5fdcvARa2uLcF5R3hd3kOCvxMTUQb1XUGfSB+Ju
zlLYzWJV9Fev6L7P8x/bFX3AdqPL+ZWw2liPD7Y0SRj9LAp6B/FV01Dk10G4n1TTsg7pYbup
h+MyeKbZYBle0nOmTZTxZlxJ871F1mzMMaSfIrdldEkP583QBCcWOzW9jEj1K8zjTdZqwQjr
zeiETqc3pBe7Dbnn9aG8G2nIhhf1PDgVkX6j5qZ8Y1Vm4aDGs1ZyBPSLVNL3E4fKO9Ssln78
9/c0tlNFv489N2lBb0n0Srmh/uuFTn7M33BAv++V67qoZzfmJwA9cZ5K+kZ3MNaXYUm9XD56
XIocmizR8+myZmS7B+dB4yX8kPKq6PmOVqfJyz0ISbXBPFSY7UaNTAnoOQ4nevfInCp6zD8l
VPRv6Htpiwt610mvJ6SaVkqcV98lX+SqSUuoIWwVq9aYJASAngam6Dign4K/MhT0SqQPNd6Q
djMZAnqU9MMwX9Lpl4ZsGOhZvKFk+miPJbvpxyzScxI9VHmL/SzTxzdkRzmdPu/V9Mpu4zwT
zqQg/QDX8zDVe1bLkIasV+c72g2V8izlMOjnMDQVX+6XP+hZ5v7LzT2NXbJFMBn0ph1Lyk2H
tGJRYm9ofWWfGG04DaHNBT30G8tUj44qcf51/GHthuOLW13njT/D0ifRK9BvaLdyb7qXezQm
/lmivEBv5fg3HXqHRBsWaALpZS+hoo8F/aUUoN8tYTdB6cbfjcUALMcUh2j03mzslUPqQv8W
6fWQbnQSvRNgqcv5htklfO5O86nvM+gtfCG2BlW8fQj0+jU26eGvHKIhquBRIn2oSo+i3Vo0
ZcSbKnHN0ynGpFiO0+qR6PlYKul9Mr1Y51mc9w5PyIpMH2WnH53gbbKa9Mz5gYI7JMtFvlfj
B/UbrulZoFddWauC9+v2eBMX9Dr0Ri4GPppasAr0i1PSl79Gz3Vew+efU0nPGcUP06v0PuXm
g317BPQf48fh537Og/TXwW7Sb9CTBeg/Z86jpIfBkjcNhnPeJN54Ej0sPhSOI3V+XY+VZXl7
Zfx0ET/+ZQV66yrdBOcN6IO1O4E+RqTH5pErMjEVHJmSFbM4HHZzkP6R0I0FzdGMvXoFI7Mx
tpuD/yiX+E0EJligt203ppxf8YfAXeJ8jvg1imGlQmEYu6Z8qWYAPWKKgyU9/JWjsOGEgH6c
nfThKr0v2YwdlsZO2TtGKn0Q9J7HkpLpffOxvswbJn2vgjrKe/LaBLqz5LVUMn0k6Y2dHvHF
klZZQFC9U9Inkl45Js0eKluqAbzdtYM8ScWjsdbQrIg3CvQmzHgBAj0+tOw1ei7o/w2k8p72
E2S7ubAHqE/puwHoZb5Ve272COlv4EfyZe25sYB/HTH0hGbaIAjthkt6kJ59N2oniQ17X0mP
camARM+s32zl07ekKbmW633KCfSWP6nlADj/zkv7XwrHOU1MxXVj9z94EAl6040V0D9IBj3W
iFNFfzUe9FdVyMXfroWN3qvoLZFemW0a6pfrzo3+OoMMetTwLNPDRi9yva+ijwI9bDdhoJcU
hHCV3m+lr5/GbirhVh5PNTRSFVvSUzK9hJtFDcjyYkEOvSG9nvyWITYc0u1LUtJHkt7Y6Sc4
fb5X9pE4pKdCn2z1kUq9qO5Wre+hnujtLKMSkw3R3hqlwidAexa/FJAxf5GMN6QrlLPrpo+M
GIepJwrtBvulWmGFl6reGCwjMyz3tbaJsx0VNsQXfKQCfSvVXsGKHh3Z61LUo6vK2o2U9DQz
xaR3i3rNeV3SKxc9x9ejF2uk+w1tNunLKbS4jEA/6+nzLX9LnH8nci4qCfRf7H5w5RLCz2JF
+tQVPQz3tHjk6qXYiv7qj5mr/xOePQj0WBXr+yN+olzTymP++XNeFK12g0eDfsKA39JuKKj4
Wbh2I0768JLetdJP+xuwSSX9OIWbxZrphzixeHRojP4C8kNHZdlXr2T6SNL3k3oj60gg0ei9
Uw7pqdTX1puQniwL9MpOr2lvUO/OTfUT4lHiO/yXYh6LSIB4/lSLkoNQ7j56zl/616+++h5p
Nyjp2wzqk303BHpT0EOiJ85LSf/z53/1byNAj6KetomfaCTthkt6ttKfINSD9I5+45T0nkRv
KzeC+xvWdsEyWiNbPqDv9zhf82PmfGTSAaSchPxKAj3bK+O6sZdSV/S8SjCpoj/GgsyvYNrc
cihY0StTZcN0OXD+ecEGPRIQuKJ3S3pIN6Uw0GNiimw3YSU99scOEejDVHp70VTVJM1IUTE/
XAUFhw7l0seW9NSPLbjhZmHizSA1ZaHheF4bF/jW3FQk6EeJ9H1c2M+QbKOOQ3rHeuNHPU9K
BUhv2rL0Vq/C19zH37bpnklPtT5/Ltt8OS/9Bl8vX+ag5w3Rx5TNkXfG1tUZ1EdvFJR2rCfR
8+IQLugZ9K8cff5WCOfJZImDpiyX9Mp2w1Z6buf65Ru3pLcWDyJWR0v0Sqd/3+o0lsdPOyGn
bEB/1zPQN/yGOa9B/461Ldao9QB9XDd29+4g6AOzsZBuroZq9P5uLLH7WDjoraTiq/9AF/Q3
KOSloncK+nfkaawsynl8l6MMehVqNlso1AdBD/x7oLeNNwiynKYKP9RgWXBAb4/HombnZLNp
nWfTO1YFzCvQVyWW9F64WaR4Q4nFfHxNWH9Dti+hITtKdno6gyV7dMqRb8h6Y5su7TlZvEnq
cH+f1nPZeEw3mg2R3RLzCfwEei7pF9KONZ+TWmDlG4FwnzqxuR6A/r3PNx9BOxY7pk51atQn
7I7dd71NJVfqaSkGPZG+5/lRacv6DoMelnqo9NKOfZVHpgB6IT34DfnGc9/YJf2pnRJfL+ZK
Kv6tU3eUg6Tk9/f+sqjrygj0lrGy+0PBPMp2TrSZF+gfXDmYpqK/grCbZJHeA31s3A2nIOwF
4EWjV6Dnv0Sez5VNgukkfz/eIsEQ0EO5L3iavaXdUH5lOOhntUgfVtJLstn0sJqOKkwx5Q3p
qaQPGCxR6hszPYWb+ZZNOSU9rDc0NkWxN5EBZ3puqj9Bpmc7Pap6bBeMJL3fXu8NytJzwEye
y/GAI0dkeFFrzL9FsqfXWqBXndh+KennNTTl2vX7yjvUjLuYP/38vfc+/3wzRPr2E6jpO+7c
UVU9tWUjloRTSX8dyk0HLQKRVqxSbgj0J/f9q89CK3pV0tM87a5GlYGAZxiKsKRP45dvnJLe
luiN50Zb7DfUHbWK1uVbGrc67JXerzu55pcM6CHSR4A+wV+5+2BwYspf0T9AfCWsNKlBfxD+
yljQ/xSX+t8h9gagP+RU9Afljm9YroWwyVVEFX9D3IrljbHPVDC93Y11QG+V9PBXDjP3gyV9
ob9/OrKkB8lHtZuyiKEsX7ZZYklP/diJmH5skRJvfG76MOST81IFWUapN+y8Ec5Hkp6sN3ZD
1kxP8YISEF4nWYaU9dbclCno+ykQTUUaM6FFnVd/o6Sn54J0xwW8eamspRt2YjTQkOpm4nxj
e1fXia4OYj2h/jRpMYL6h4EDntvKDfw6ZK40Iv3HoQW91m5EpEdJv5koT5zXqNfyjS7qvZKe
lZtdFIgWlOjZZmmFFpeLybJMpBvLWHntC8V5Dp6PqugT/JXYJZhou3kAjf4qjcYm+iupGUs7
YxNAvxbP3kcF9Fu3mop+7VUlz7fcSwbwcr3HlF3Rw165JgT0UCos7nslPeUXR4AeKQhFBn1Y
ST+hKVUYliFZXdHHqvSWxZLCzcRMHyLeYPeg0m36YaqPO+ymj23IijzP68L9qLeEemrI6tQb
y37DyThsrISAMxMafCZBlgxgsVWqY/8br2LDDejOlvxBx6mjfx2QS6pfigC8fnU5SzfjlMmR
q+sB5Y/0oKZub98F1HdVk4DT6VT14aAn5eYElgTuOtFBrVgNemJ8XXhBz6SHnZ6pTRnFTHl8
aY45Y/uOkm9847EbNmB7iYkorr5jPDeefHPKNhA+ry0H/aY8QH/ZiFrf77ikBHodfxAu3QD0
sf5KD/SRs7EEeoqvTAY9loNvObb2bBLor375/PkbV5R042n0++XGXVsuiKf5OkUf6B/rFSQW
2rF2yh6h8kifzxfkhUBJPw2muKDXKv301ISqR7mYl+OSPqKk90hvLZvyk36IFHyQfoJk+vh1
U7BfWnNTITU9B97YJX1UUU8NWdt6wz1ZXc/TTCy9PXwXFbVrWaa3Cnqp3f3ijS7tZ8JA75I9
6T3KeMPUXR6J/92unp6eTyDbkG7TdQKwN6hv20BmS6rqg6B/uIc8N1Bu2m0TvVfSx4CeUm84
IUfV8ZRZ7JHe15PVJT3WVEkWvZLoHYVeXqi2whBuNpRDY6QsQC9CAp+bx7RuY/LMQkkfCXoJ
Qdh/lir6eNvNg4uUahYKel83VkAfXtHb3djfPH++VVX0WzbqZuxLfLu6/3Ma/i7b+7DrRmv0
yDRTIo7juwHovUAEOwcB7IoA/TOQh530bkkPM6Wo0FgpaKUV+8SbRJWe52Ml3MwHenoDCTvF
oSHSb+J3hUu8mZbpA6QX2aZ/gqw3/aqkjxDqCeom9UaKeq7nNdyp5jdDUy7xifBovfp0eV8/
Vm8UV+3YhIK9Pwn0JI+W1RCPebjXsnK7pbqLOEuURyFfXd3VBdLzS1zVa9SHlPSi3HBBL0vF
vRNFeXo9KnoEWZL9XtXwsmvKQ71Fegg4Ano8NcRJ9Ir67dbgVFlYMMoB9L1eAn0ND0rppVIy
GhvajAXoL4aOxirQo6I/6wd9QKS/Cj0G8ZWJJT2BfuPaS1TRx4r0B57/gTjP0g0qem7Dit2m
oRx+e7OeRthHHwJ6m/Q+0HsqPWw3sxGkB9DH/SV91ZgmFEDvcH6uJb21bMomPYVb4pSGJtVi
wd4k0lvxZv7BKSnnS6OjE3qJbIxQT1QP+OstttvU95X24psnUcZXw/sC7OlFVusHkjieCHoy
g5SL7cstadh6frjzMy7iT4DrOB2M+i56DQs4bLa8Lr5JH+v36J0j7ZJzY4QbZaWPKelFuaHq
nKw21Xr3lFLqjXwjlnpV0nsSPQ9XuZ4bXd5vtkyWN5etgIv+QmUAet4eJud2k63b6AyEcNvN
xXDpRoEeGQiJRnqq6Cm3PgXoodFLRR8L+qu9b2rQ64peOH97hSPMAvf/iA36Ia+i94F+1m7O
Gu1G8itDtRvsE5wQ0ItKj+xjzTG45FHSW0vCbfHGeOmt7bEhMZZWP9aQnl5HHntgnkA/ROJN
KUGmH6OGrPJYOqSnjAQEFXO4ZcmW6SPkGx/pOTIBNb6BOl4MeCzVG4nevtkp1u4t8NOTwQz9
JpSupE94JiiQPLIieyuTOMcduu4LHdVSv6P9SkdQDz2mHW1ZQj3sNIx64riNeig3CDSjih5b
wXcaE73Vj40gPWz0WrnhXwagycM4KYmWouWI+0bHnNmg518C6HklHPR1G963TJZl0J0rA9B7
k2TdvxHDDVf0ykrPCo63N9Yy0l+MMdLvf3Al2kivQhAeHEROcdqK/tgWCjVLAv3535FEb1X0
ivMjSQ/15X67hJqJj/4/o3TX0o0NeiRbOqA3JT3yK8cV9f0qfZWn3czalB/j9iuSzUpWhOXc
VfrxkpmPVaAvUoKxxryQniZjoeEkN2SDpJdk47wKMSYRp0+LN+GkJ+uN15DlCDRnpSxP0EbI
9GyquTvgxls64g1X8rqkRyx9knYT//ZR+sV5JXcgRD3IWc/OfdTZcQJOG5qTwphUKzSVTkI9
SfWBqp7Eeu8A9BIyBtVHdktZ0k2E5UbQf12UG1T0zHn80gD9XSJzWLVn1PtJr58bzCrxEI2e
XmWZLMtApF950HuNWBgrhe9Mc+29iQL9xbiJqf0PrhojfWQ3lkFPYTdJtpuDcN1spJjiMNBb
Iv3BH0OwwRgW+ehZoxd9/lYZPKH7f8j4GzsvY1Lko9TLpizSYw9JOOjhryyq7YJ+0FPcjTJY
1k9q7oyOK8GGSno7ld5PelLp40t6Em/UsikivcJ8f1Etm2LSS7pZCtLreDNT08veQcg26pBM
z0GWAfONyb6x15Doep7FHEV30uxjZHqVk+AR2klCEAe96tliOnZhoCcnSK5cbN3W41EcKj9B
BQ/Qo3CXtd7XW1vbEC5JqEdV366reppOorasjXoZi6XaH4W/T7mJF28wF8vKjewf5Npcdk/J
kkGrqJfhKf4//Ji8LvaTT6D2RCk3RPovPUl65Z0YKw56aQvyaT7IeJf6XQ/HItgsXKQHoGNE
elT0emIqEvSXwOQr4aB3u7GqGZsIetkey6A/BtBfFb9NTXkFU8uPGD8GL3NJD9CPGs5boB/2
g16X9PBXlvQaWR/pZ0v9/cPQbeqndKE6Om7V8AC9vSQ8IN5EGW885w0JNaofO1Wk/BtMUVmY
Z9LTrvAk8aZIxXtezU0J6WXvoMg26pBgT9vCY0jvWW+set5CfYJMf9eU+4ritpmeFHzx4VBt
P2LPzc6D+fSbcxlmmslapr11EF+ooEfEDSryX/96zwUMQXFVr6R6G/VtH1ioh4uelJsueG6w
mQqrvZ2CXqUVh4o3r0Dbl18FlCEeOrzZPWXkG6+oF85bS0eiJXoC/SnLTLjiQYYrDfr7nkC/
4xgR3SnogXzSZ8JI/wVt/47ePbL74JUrasdUNOhNRZ9Q0lNFv0VV9PEivQH9RoBe/PM1K55J
HPYrM39rm3RFP+mB3iM92evdQEul1zzjtbHhKj2J9PXjwD0fojwp9fpQYKXbjnX7sTQ9q3fG
RuwgITM9R97AOM9nDJW9V9AT6TndLKmkZ5lez00R6V3ZRkjP4fTaTe8fnlKJCHpC1s95VdXT
qyNkei7Y7XKfnUmemZ7/qXIRCPQL027yJNGXU56iPCxlVcdW1OQEeinosSz23LY9+wj1qOpZ
v0FTFgq8cuCg9FZVPSk4bK6sPgHHjpVQnMp3Y5QbAT2KdiyUNUW9Ir2SbzgRgUlvB91ESfQS
e9PplfTdM8utzvq+3kqD3utN1+wlzUbp86qgxyuiJ6Ziu7G7D0J9j7LdKJGeK/oHJN2kAv1Z
pFcmifQMeqyMpYr+oHB+he/giC/Pz6/NwnfsDAwDPTYMPvNl1Cu4q/zKsH4sifQu5W3Q4629
doU/j5JeLZuaVJgfnQTnXdLPQbyxGrK8qQQ+fPdQQ7Y3Fek5o97vqicBJ1Kml4wD/5OAZabH
MBUvqqLriX+PLEy7eUb3+LpyezTKpOTW0211jHNS6Fv3/frc11+f2waCC+pFqocBx6Ae7Voj
4HiBZmjF0ofb5kozHhte0bNyQ/vEeS1V3YZXcKSop9XhLM+IfKMUfCK9A/o45WbDBlFu5az0
71IrDHpvnW7DG7oJa3QblusjK/rdCaC/EjTSa3+lBj2Nxn6TDPqDc6zoCfSo6Jmlt8qynn/+
3AI9pBsb9KakB+jrI0GvbDe+oalnVQhB0LX8s5ClgoV+Z0l4YGqKSnprP3jYXkHeFK6M86Uh
xnyA9Eq8iW/IksNGx5vRv70urAV7GpI1bvrwml7WkIRynqt6kulD+rESZewPM6YxKx2Eg3/0
EvdZslmodtNLSM2V26NR3OaHTl5v7eSCnpUbFPRf4xjUiwGHUA/Sd8EHg3ezUK/yD/A0wK1Y
v3ITrd3Yyg2LMCjohfSAOVaHW+4bLd+Qii/d2mSJfsNei/Mr/svUyoK+aC5F7prnnxd5Xk50
2s3uiw9ijfSIsVEVfZR2QxX91YvJoD8roKcNUwndWNHopaLnHLOGMlsRbAo6Bv01LuQRUzll
VfQ26KtCQf941PgrrfFYS5efGK+nTVMhQQjISPC3Y13xBip9f8iqKSvdjJZNaUdleI6lJ97E
k57EGp6bGpUurL+cZ96zm37U0+ld9w3LN7JXNqSeF4s9PQeERCGwo4YK9UAWjtCf2S6EJ9CT
8XIh2k2J7vEyG5e6K7/PH9p2srXNasVSQU+gP3eGdJnrp8WAA7yz1xKoJ2O9iTsj64wai4VE
b+XcJA5NkblSWWyoYmflhkHPpAfPhfS6qK/eyQtJWKKXudh4if5TT7jhm7myv02tKOj/iyXQ
7w8HPRIsI0T63Rcj/JXspN996crVS0mgv4KJqW8o7CZpbyzy6I1GnyjSM+g3XqT7tnui3H5V
1t8Pj5w3Md8RPC9x9PoouqOi94NetWMnVX6lp908qyp6NkHtpA/bQALQ20vCnSQEAnxyST+s
RJsCx97oit4v05PzBlbLWNLzFhJ4LKWc7x8NjTgTN3006Qn1Qnp/7o2ZpCLSBzyWEm5JGA97
Ez0x0NtwUfGOnGdGJf28fDfyRMIexmdl9XDkrgE4f27PBbbNsHLTJsqNkB67pQj1yoBTDSEe
qFcCDufVQ8ChN96prqaxWPlw21sZm4OA/AOl3EjasAI9kV7LN9pR71nqyWlP7Vvtoo/wVm7Y
0CaJtbe8WrZvJa/+ioLeE+hbrOQDu6BHJn1kUHEs6PcT6P8oGQhRe2MvwSCzVkAfL9IfvEoV
PS0eSSPSM+jX8tN52cQSBx5i/DN2U4NeUop9oEeoZQToTX4lkx6lPGZlqQTt70fEPP6rUhDC
SnpMyeZdK70v8gYlfT6mpB9Wok2vtt5EkJ7WCY4mkV6WhUsXlhcM+hR6fpHd9OjLxhT1DPpI
zssTgc9jScr9ACn4RHP/EfrjTfQeuqSndBx32Wyi88b+vHSHl4Gd23ogruEyL3fg3LaTSJMX
5abDU24Y9IJ6SPW6qu86IVU9jbHKtCzJLFTsk3JDHx4C+ggv/StKbue5KNh1WqWiZ9Ar+YYT
EbioFwfmThyo9xr0cRL9ViZ8rssbE1rRIMuVBL0l0MvqQMtXqWkfbbvZf/Hi7lDXDVf0+y9R
AnEU6EWkP4uKfu3ZFKA/i4p+49xAzw/i8pw35581LjRaGO1m74iP9GGgl5IetptR1ZelUl6f
ofrZNWso7mZ6jZqODYo39Dzgs9K7pI8u6eGxnKSBKck7kMgbq6R3a3rOLIbzJr6mZ9JzFzZm
FQm76eNIr6QbJwvBfYFCcVyaG9cl+N0XJt7k8zBa8luopJenhJTaTUhDoMBm9TLabPf8+SYu
hXI/eu3cQ9hmPM/NhT2qoBfQM+q1AYcEHK7qkW1JyQi0mgRee3ldMOfG1Pbhk7GOckPqvnDe
I30dhHqBuhmewtfX8I9z0ddt+Egq+UMn3pffW1aaBysIell+wfc2NWJdX6UBPZgdMRob668k
0OsMhGBFL6BH0X8sdUW/caPS6FNJN2vpZpVrI5ZAz3VGDfvon5UKs05Fr1T6ZyEVvWSb0TZB
+gs+Sg2VUhUgT2cWNfsw/rKDEDgMQR2A3m+ld8PNsGWwEF7Sa0Ml2OeZ6T3xxkd6gB6BxQlz
U6LakGwTs4qEtpDQFFV4UV/gOaloiV7L9FSdm2PNUYX0YynKvo8ref5NSen4I3ehAEUMX8kn
jn4jxx80rKR04Pva96UN2/2z1147xwNPMi1V13Z630MNek16aPXGgIPinYZlKfuMUnH4UJHP
YWi0FTysoA/vxyrlhl30pNzogl6BXop6PSZr3De7VI2vJPoo5eYDtSEaWfdHPa1+BWX6lQP9
fe/271CcD6/oI3aPfIGKPqYbe9ECfUQ39sEVaDecdRMv3WD2FVk3GyOlGzvAUoVXcrp2sYx+
sPzfCv+c3Wa+15cKOqXYEW9Q6QekGw/0s/VDBlvFaUV5Ij1q9tJsdElP87I+K32wpA/z0k8W
VNrB5DjPx8r+2GiZXgKL40mvurAs20STnt30bKsPk2+Y870cVBld0+sBWnXJ6L21rxITV8FW
rTjolaiDji0hHK+YGYwFfUgpr54B2MVYRjk3o1LmHv7otdceOcoNm+hFolfaDRX1WDcCqV68
loT6E4R6stmcOMFaTiOHG0sUfVCij5iOpWkpDjRTJnoP9CLeKNK77huJMT5CWg4H3USB/isp
YfdS39YLp8+tnJt+5UBvCfRrTUFPgrx7Im03XzyIyq9k7cYejY0Q6R9gYGotLY1N6sYS6L2K
Pqmkx2AsG2hXfuw55omGe3MNCvSl/+hW9FLSo0k77HPd0ItU0ltEKY3Xu9OxlIKAV0WV9NN4
87BfpXecNxiqCpb0Q7xOHEnEw7Rb0Morjia9GpuKqellFhYyfdEifYhQTzK9TMwGUS97Rkol
VmeiSW+WiXPlbYQbeimsVSsee/UEgJKefx1g7SYS5nFvWEeFRxkV9JelyPvqtUevvfa1q9yg
oH+kQW9Kesg3jHoy4AjquSvLYj3A23OEtpVQRR8u0YdW9FagmQxaGeXGlPQcSewr6kF52VGi
GrjhpD8knO/msITPvcjileuSrBjot8uloLryb02UGVXoPtBH2m6+gO0mvKIX282Vq8ZIH1nR
r0UmpUxMxXVjuaLfiEhjXzdWEg8o00ZFEstcLEDPP1fl5ll2sL+eH4fM96pSyV/RM+lhuywG
Qf941lLli1XPeETWQT26slUe6AO7pjA1OxoAvb1WMKjSj9NELZ3ilKyQtfOKI0mvM2+iSG8E
+oHesRSkl6gzH+kLLNrkS8i+ie/H5q1l4uy590pzKu8DlOapWS3eQ8mhd+/DzFTfvEp6DlKc
LZdfMO8J+HIHXsN5dEaUG/bckHKzLQT03507Yww4LuoJ89hKxWtmd1V3+gLNYh2W5LlR+Qei
3FzXGn0I6Y1SfwTbDjd/fmRzLOh/pND2A1k5+LoXZLlppe6ElQL9iBFuTGSlGoMNgj4ikn73
pSTQ69HYCJH+wZVjZjQ2BvQHGfRIKTuojkq0oWWB7tm4diPOlq2cWfl0pe7SVF+XI4ZyDPqp
Ummdr6LXoB9zQP94jd16RSDlmtAgBIgzQyTWR6j0oe3Y2JLeWzRrMm8o8mZMazdRMj2NTU2Q
eBNqsqRMesxIcehNAVGXsfINyfSFIOmF8wVwvlRia010SU90H5Q3czyOhXZ6ivCTnsep9Dvh
BRJ6yIYTr91EPAvwr2/lEIrOD801Itt0/wlx3lNuyEZDY61nLNBbJT1Qv20bb4el2VSq6lHU
A7+o5rFnFhvFj3zSTjb6cOkmxHejlRv8YsAm+tZXsIfEaceKfEPGed2TpWoeX40OIs0iE80+
UnD7ioJ0aLfsl8ZHnsun+vFc/HdaKdB79tLm/RxwE96LpdHYSCM9Mg6ibTdU0RvQR5T0LN2E
V/Q0GcXTUVKlH9u6Be+rwL6R8Q6k03+PMdvpbKV9I/hrKxf0K/dLWroHCT8WuRlbDAE9kR4V
/YQBPTqvU5iT8o7OrwxG3pB2A80+YLzR/Vi8eSi6pMcCWQqx9FR6hfn+Ie7QSkU/PkV5Zkal
jyC9DiwOI71KMBsD4EW8iSe9hN6oABxT1WNslhaEM+dLJZ6ATZbp2Ww5k/cy61nJCSDaWS0O
Aw7egXw3M7HaTTjot9N93V0mEaq1aj30xW+F86TcbMBYLAp6rJFqJeXmUVC74ZJeinpo9Wyp
JAMO9BsG76uvvvo5SvoTOyn5MlSkD5IeoPcSikm5oRWyYaS35ZsjR+SrvYrnFXy58Cz6cwrr
uX16hvYTL95spQS0FQK9d8Nbtjqc9ys3BPoo200s6PcfvHL1op6YigA9JmOPcXqlJ9188w0i
bfjPQargWYohkFOoAZhO/wPTCe6K7uD61q2HzKEXOLRyxePqEnjPv01yTvFoBOih0ZcY9ID8
pBe8Wxiun7XzK4OJNyLSR/ZjsYokYKW3AotBc4BeqfTjY6LZFEwugiL9kG2xjDJZeuKNr6ZX
qk2JM+tphWwv/SOuppdsepf05Luc6dOcZ/FmUCWdhfGeCnk8EUhigh1lnOe3+A7vj9WvQ0mP
mp8NlrHaTSjox5k7ZWKtrJdyPnfo7bcF9Gd+rTw3lGfWdnpPOOhhsrRRL1U9nh12NfZsZvC+
ipIeKcUYmJLFJIETcFiycsOLAznnphWLwkNLepNyxkZLPK2YLxcB+g9kUgrWSj1D+0nje56b
foVadysD+kF1KVBoNKnISr0/UGPf81cq0AeWj3yBLYDRIj2B/hs9MRVT0V9VoP8G5+w3VMRj
0gqEJ0cO6vUt4DqTHLU6EZ4w79XvDuMN7OkHq0yzzDz6c2HF8ZUoRv3KDbKLuaIH6B/XYwGV
muXPF6bqsS8cM1IgkJZtgiU9DJYQ6SPFm3DtxhZvTEmPTSV0Jmy7pSK9tYIk2k5PY1MILPap
N2Oi2vSjnOdD4g0zP64lyytk9UAV1/S8dJASz1RFXyKEoy0bVdSTTD9TKLiLZgXlIf1Yejrw
As8g2ctwVbx2Ewb6Aj+ll0f4wX3Jqvz+sMg2OF+f2YdAM4zF6uDKMyjoQ0p6DXpd1cuwLOSb
niNCXpT0aMd26M2yiaTH04uKoufAMlZuwkt6Cqzk7BveIa5Aj5JeFJ/AadWc75aVg7JE3NpC
Ukj3K/civ9fKgN5rTuxgk7yn3OgXjFKPiamI2dgvLj2IAz1NTAUremdv7EE0Y6+cfcDnGzLT
gPC0jQSFPmp3rcYQzfEHLxrKK6VG1Br3YIS2jAqo6EcLN8M5A6FUsuLoraEpVPQFA/lCgTR5
UF5KfMDpmQoqDoIeJJ+wQe/vx6JbG7TSOx5LLunHS6oD63PVC+kpxTI/bmT6cPXGEm+8mn5i
kDk/YVZQjdErmPpxpPdkeunJMucl70yTntqqVOBHoJ55Tu/jDtGS+h4Qb8Scb8ANxvcy6PHU
EmOvCQM915IrOpRpHoTb1ezQ1rdVPS+eGyTZMOixWUqUm1jQi1RPWj0MONUo6Qm9r4t2s4vW
ELahrRpS1ftKeiuKnoMrSbmJKOlN9g1ID6WIvtrrpN0g2Tio3Zh6/vs/5bAESPT0S0O157Fc
GfFmRUB/3hT0LWs16HndCOUUh/orw2amvrgUZaQn283+s1cOmrCb8G4s7JXHxEuDYv7sQdrl
bar4IMNpP7iI8/QsQOk3fKjmxx/R6nGObaSCvrusLTf0k3ePhNsaAf1YYF4Kbddhi1fD07OK
8QL6x2N2rJlfvFEifWRJj8z6/qBIb5N+UhDPRpvA8JQq6SnFciiM9HY4fbFPZd4YnX6MXJfU
hLUOKTks3sSRfgLLZGdM7hm/5K2fEtSLeMP/Cj06/Syg5FOx7wxU0XMCSn+vR0viDsF/rqAv
cA3d3bvI9eF8Pl1eyRfdfyaqja3cYAiqg/ILTsJz44DebceKUI8jqEdwwgnRbgj0qLHJJwm5
HWH1IVK9S3q9LVZNSwVAr730xlHPw1ONn3BFr74ctBs/6Y/L8lCcrXraimOOq3d54s2KzDOs
BOgtx83fCtylE2v+66bd7EdJH7565EGM7YZGYw+ait6n3fzxj5iNfXD26jEQm6R41mmOMcK1
NEPNVcY4MxwvwKGjN0j5zDbafLMRnwHPA0TQMg4/0D+j1A5nf2WpVLRBv6Z+GEtkzYGD8rEN
eSE91sZWORW947BEVvF0aEmv+rEAvW9JuBNuhn6sonx/zGJBSrHsRVs2PgthFKTnsSlF+gIw
PzjYR81X61BrVlX40UJ9CWxH6A0fjjqzl09JVU+kJ69lFOpJjA/t2PrFGy7xnZJe/TIwgt9j
5nI4ZiRXDs7Ka8qKcsxQnpSbbaTcUAYxrxzZt0eUm3jthkgvBhwq6bV2A4flJ1hNwgk4Zi9J
5PJYVm7w+4BsK4FywxJ9ZEmvU852QbuRil6X9C7pW00E/WFIS6oXy88lO294zpv++TxPLvBj
VgL03qjUDinjPdAr6tukjzHSX7oUY6TH1tgrOuzGyzX7I2k33Hw9ewkFPVAu1D4GtYYUeVbl
Ce/H8Bp6g/bGw3WDf2qDpW20xJZYoF7c9Di76UdrzQLvlmX4cEYAbDfrSqUhAj03XbE+0Dm+
FVPahPMY3dghF/Q26WGwLEoegt9jKYX8KIZnY0r6KiXNF0KXTRnrDW8VTCL9UD9Iz5k3RHou
5yHb+xeHc46lkuyj5Rto+RR6o4LOZgasJYNawNHiTRTqifOB7SR0xdlM7zlxWLSHjcfTaRT5
R9BbmAPo2Vj5/YqZt72H8Tql1h7+M6PasERPyg2H1ej4Az/oI0p6Rv31tlMdXaSmvId6/nMM
TdEEFSXgUKxlUL+xS3ooN3dkW6ysHPlAcT7UeOONyUpJD8xzT4Bzim3SHzecz/1C5m5VnjFA
f8oTb1ZiCckKgP6pJ9xcSQd6qegD3VgY6SP8laTdYDQ2xF9JpTwgT0INdBsq1KHCMNI3cu0u
dF975Sq6sfhzkIQdXgO75RhsOGpiyszGGvTr2Sn8Tb2Y8ldunj/vpbthx/anj0ul4XWP4ZB3
CE+FPAr7kMlYfhVE+pIP9Bbpqd2qkm9CzfQR7VgWb6qMbBOReOOZLCnyZipJpsfTgWTe4JCx
Hgk4fszTy0a8iZNv8HTAHkvaRjJD26ic8Sku6kly8Xw4fgHHWR/uvJFLet3zZpFGBmgN1PEq
/G8gQbvxPQcI51f+18uS0i1ypM57wg15bi7QBqlqbsW2oaAX5SZNSQ/S05MEazeEeRqO1Qk4
vPcvoN/YoPcpNx8oiT6mpCf3DX4H4JJe2XxgpXdIf91bKfVndRswUysuegrHxBNCtSfeXF6G
Qs73JZYf9F7GTTdlVspGWNkiqF/0SzfirwwBfZSRXkAPI72Kr9QVPUH+EkIrqYSnuh3NVPLH
8yGJnsiOluyVg1d4bSD+LWind8cSWM35uBCEg2W44CH8YUXaze11jzEYa4sNo+PSdEWNj/I+
INoo8lMIgmu7scdjVQpCWEkv4k1oshlZLHUxj85j1KopD/TUj7VL+vCGLLR8EW8o/Ibyb8I4
zx5LXehH1/TcxBXO97Jc75IeqCfxpldfUb9Wr+LPIvV7rd0T9UmhgUrvlPSi26fXbsTjsuKc
n2lSqs3+nxHnLdCL54YTipWJPgb0lvGGxRuEWpJ2Q1Z6HME8/Y92ULF+A9S7TVmP9K9gWYmY
K8Vz43E+uqSnPASIPTborb3hcN/8Qvttvv/+GG+ikuB69TXqNrzviTcjy0765Qe9F/xAWWYC
cPnbUnAs1BsjfQD0+2P9lbtRkT/wQM9yzSUEVoqnhgUabqYK3ck6f/bSJbRllZMeZhyP61eh
0h+LA72Va0YP6vLbwRzywOJfJSHcGNCPVc0y4PXBdnC8IvxgeGo2sqSfhTYz5Zb0rvOGks1C
tJthlXRQgDQP0I+Gh1h6pKfIG2TfJFhvMFsF8YY3hmNSNhTzeCUvIdFvjEI9W+7FbuM4LT3e
l7gY9y6q3ZaN30QF/X5APQVwKY9/OyU96/tQcwZTazflwfnaZsW37r2MeZv04rkR0Kv4A13R
hwXeGDO9gB4qvfhujvSoYn6XSsDBlO0dluqh34SuCXc8N5xzIwp9nEr/wQcAPbQbdlh+Ts1f
Vawr783b3hqlw8e95EsGPZQb/I7hiTfL775edtBP2MKNBr3ntQnabl6iWLPQin5/rO0Go7EP
FOgxc7X7EiCPGp8kGvHNkGBDYvyVs9+IwZI8lt94/7ZAf/YqnhliK3oL9HT7ynfhiAX8WnpK
uslMGoJQE4hBeBqyNNZQP9iNtUt6bAwsSKBlxHxsSCp9lZqN6h2rgoIzTQOx4dtjvQlZ6seW
aE42tiNLs1W90oTNA/hRBwzv0876SPeNLCnhfHpzfPoNhdoY8cbuy8qklIjxIYdd+PJ6qtv1
P6DniB7DTxODfam1m4IoBStdz19WlsrcoXOvBUB/Zo+l3FD8waPXokGvpmO18UZJN9UIsuzh
kGLaMMhRlhxrWU3eR9JvUMYHc+n9nhu8VxD0rvGGE86QOkyg57MZyWacfIkQS3yln3lpvLkz
KOi9XizeRZYQWuLN9HKX9MsOehPD3/23PzQVvRdlFkw1i14b+wX2vUZ0Y6Hd7D949dIlIN5k
z19h+yQp8azUQMK/cgUvXaHNIzQ1ZXBv/mFKetoDixVTRqOP0W64F7sSbfW5P3J4XfQspBt3
wZSp6OtDc4qF9ejGFv0VvafSU0SlCrUMJ30g2cwq5gnz0OrjS3rJQqB+7GQi6anwF9UmLrWY
nDeUeSPHruntPEvx4EvsTTjqCyB9n1XS676sRFYW6M26cndxT+/Ar9EFPf8LYQnqUEk/SDp9
Cu0Ga4AlZGSFf7c8r3/ct3xWd0Zz3og3j7RyA61F4g8wKhsQ6SPbsZSGhj4uLxfkHuxOFWCM
GpoXyxr9RqNeaze0ZtYoN/DcUOM2uaTXoN8M1OP/FGHJw1BUr5/6kcf57/+EOO/1YlkdAufr
6jznzbJHHi436Nebgv4acd6r1M0kbFgIghLyfck2X1yMjDUD6HdfWnsQ2g5tkkI1f2mtDEJR
oxWQv3Tl0iXw/AqKewZ9QoDlHEDP/Ziyd9Hzs0KRvtUWNGOjQT8eJd1gyVQhAHpDelozxcOx
UfOx1I71Uum5fBfTvDcgS9ab8WjxRkhPwfSUaBlb09PTAUhfUOabVOJNBOnV2kGX8z6pHjO0
jngjVb1JPrAqd19dr/qxVvwZ+etNUBq/Hv/pGzTsV71X7/OYtzwVHWFlOb9eD0a+dLyrIwT0
2nMj01Iw0SO1OH1Jj17sBtL3BfMk1VBb16whQQe0eifrNzDVu6T/t2TM3HkCCcKylmrD9Vfw
FJBQ0tOALIWUoaTXxyye2rlzr+EaQuhpWpai0Nh0oyV6Av0pL/pluc30ywx6rxOLLbGqohd8
x4I+XLsB6KO7sft3H1x7BWHzDx5cgk2eKU9mmisYozqL+p3+vxvvgokpeTaITSpGKA5tB09T
0dPARG7u1fWKfAT5XHPw0UeAHptHJmNsN4FurCXeIAVBDJZR4o2VSj+ONbGcZzPMOwaloJeS
Hito43V6ZbGMI32RzDk42k0fmU9PY1ODRrwJc99M9HE9j4VUgWPrN4NksffV9FbCDVXmof1Y
eh8VhqOBTQW8eV8I9AOIvsTXD/1weqX+OLWnb0V9lds15rt/1NneVVf30Eg3uqSnJYJ1Hcpz
A+XmXDjoo4amyAtP5KVlseSoVFlnkG/INtmOVX9c1NtWS1XSG+WGVZW6D4jziSU9izGEbirk
wW/6r1o8VX2MOd/AVf1WTkWwx6VYokeNX1fXbpw3uWXuxy4z6FV0HW8P5Ipem2kU58NmYyO7
sSjaKR4h9HyxezfgfhUWG6K8+j8Qf/EguqyAOo9M7b5Iir3aMRUXSY8nhATQG5H+h7iru1cE
23P/okP0uIRKHwF6ZCCEBNKrFIRACIIzH0sV+7M40iPZrMDtWKuYV+1ZTfpUJT12kfRySH1E
TV8s6C2zHuijdHoSb+yJWb98o/eUwJ8TJL1lwJEANIf0nGfcqzqzUV56yi8G1pnn6jjlP2s7
QP9MqBOfP0KFpcmPWfdKTnOYar770MOTd7qqAfpH37799unjXjsWUfSnKbiSPTccfyDTspEO
S0elf7iPvPBc0HNV3tr6AQfg2EW9Qj35b6QrK6CH54ackpbnhl+dUNLrVeKi16iVgqze/IXY
bWr4t6ivJP3GbCHEu8oELYs33l7BZU4fWl7Q580vOMi4CQO9npB1JqaiurEAfXhFD4F+9yUK
slkLzLMdnluxB6Hp41hxN99cgXM+uqI3vpuDKOidij5apF9NoH/OJf3jKNCvKxRGoyp6CkGY
jtZuPINlhHhDKn5VfVVJfDYIS/OOBv14aACCVeHryJvRKNAPD00I5pn2ykwfGVDvc94EhHqJ
QiuQ82YwBPSWgEP+y7yVgcOmS3FdEo15qir0UD/WlXbwvirFXnIvSbYfcLNy7M/EoJ+VUrph
BTtFm7Q2nzv00d+dbAV8O9tOEuhv3PBAb20Fh+dGKTdxoDcZlpSDQMpN504CPQp6Sa3ErCyt
JSGlvot2/hFjSb9BUa+tlkJ09asAkujVbikX9GG59NyLlVXh6vOqJeFHPvlU5PmbfNnJcKNB
z9mYYsGk9DMWb2S0gc7U3CuzBXzE8oLehJk17P1hNOh9Kn207Qag3x2s5yHPY+83911R0h9k
sUaUmt3Um9Wcp4r+0hVU9DqoOK6kZ9BbzdhI0F8h6Wa1VPTPhzk5Pwb0kRNT68bz+akg6LVK
P4vgsnG9dyq0H4t3wP9wWJl3jtZuJkD6OO2GZXoSZqgfG1LST1IXlrLPipMUjFOYtFAfKtRT
NH2f8xZrlyz5LwdoSooL/1DSm6qeHJiItdRxZ8x506Dlfmx4UU41O6VbWqK7ZdJhaQfmekuk
9z9dkPLTLNypub8ALCzoQ+83G8xv/bu/+/a1kx0dXWi2nvzu22+/ffddz2F5bs8F6qbKtJRW
bizQxzsseTEVPljL7FSx77v+AVBPW0l4q6ygnvQbZbXcxyU9S/TMbLhziMH0HJFY0hvlRj7p
Tr2NpOcAX+7cJoZb9wUVZ6kkevXOMj5LpH/PuFGWN9xsWUFf7xX0wPwcKnrgPMxgCSP9RX+D
llw2ly5d5UyDY1eunEXPlQEfujf2AYH+igoqjgU9rZg66E1MRVf0q6gZi59mWRo9HYwp5tcA
I1EVPdluxkJAr0k/hIWBZmN4GOmh3fDBztnAUaSnnYLBTDNfZDFNTRVCxZuiLBPvLyLlDEkI
GK5KJD1V657zxnbf0Fs039lyH3FEq6conF71T1TxxO5BS7Xn0jz0kDfTtV+ipNcFPP0m0Ivf
B2aiRfp8YUgFjKxYG3Zkh/aTd++t+/Wj195+dBI90o66zpMPv/327X//7w3oH21DhoHKubGU
m5QlPaBO8cYkyIPk9Dzx8OFDtYGKo+pR1BPrIbEYqZ66sqru9zw3FFzpB334qimJNSZHJUR3
PHlwlE21rAFvqGfO5/bo2GLZaiJPNSzRK9DXef3YZTVhLyfoa82TWctXP2TQy6SU3YtV4WbO
bCyEmCjQ+/Mrv9h/EZi/Ir3XY2svHWTG8+Fq3l/SH6RngzS2G2j02CVo/JZB0CuR/uADur9X
al/YnAuxWo7aDFrohfxjMaAPRtI7ecXTKNe9reG+yJv6KkxU8fEX845MX0Vd2tiSnmp6XhQu
a6dsO32R0A4BnzCPQ13bfgDfO6E1PckzvjdQUT8qss2EMlrS2FQU6aWqJ5mexBumPq2ecg2X
To/VkV4Y9M5zgAd++jwDbLmMFunXC2W7t8/5obA4HzB2U9sMu9949dUObIA9d+YCOI+K/gJA
3/n8+Wea9KTcsERPoPaUm9iS3qj0nH8APf4E55ghlGwfgZ5J/4FE1SM/h8enRL+xrJZU0IPZ
ynPDOTfGdhkYmvK89Fq5UVoMmrxE+o/ketf0Cuc/1ck3QYlek94z0y9rUMpygn69LuhzbxwG
6EF6A3p7EjawHxygj7Dd+CamWJtn1QbiPNT5tTDSm9nY0OUjEPI3pqnoMTG11dsOLukIvqPi
bg7SjSyHtMB0P7h8n7TwSsHgmYrOQKC0mxDbjVkUDvulMVi6zpv6Kl3Mq3ZsyIisVdLLBsHI
I4vC2WJpk35I9WCLw8MqtZjU+rFk0hPDA6SXcr6fkc+ZZngprB+r4K+3krB4MzGBIHssHAn0
ZvOhWca8T9YBPYXcyCvUkwDybvoiVhYOKVNHzd109/5iv9d6k1d4+M9ffvn1Vxvb9v16269b
q3E6264/fPvbo8+fH4VSz9OxrNzonJvW679mz01CO9bEIDwU5QY6OYIvuaBn0IP0lGqpFoh3
iUhOWTPaaklZB67nRmaqfNpNSEmvnPdinCcvD60Y3CpIu3aXpxZy20zGmXboGHOlCPduP3Y5
LZbLCHqexOTT9M4PpaI3eowD+sCSqUjQI6fYs92A8qTNk03+ypVLGHG9ctVKpLdKek6wxB8S
6cl2k6IbS9vBt9gVfaR2c5ZuZZnsbUvzc8w/ms3hoB8vFNYg1TL0PMbAprt7RAk5SpmfyPcP
a5HeSqb3KA8HpmWl99FeOSwp8SYe9KjpSX+Xkl7X9MOqBwvM4wjpaT62j/6Or+nJY+mKN8Ux
cdsUlF5PNI8Tb1QEDsee0eGFgyXXhMObxO2pWYN20m5c96TRefAPaED90G4w4hsq/KiwgdzK
uCrvGmn++4Y/f+/V119+eXPPndYL+y7UdWF8qaP1+oW3v33r+fO31NyUKDcMevbcbPvaS6lP
Hpqi3wZQtquCHh8unJeifp8U9RSKqUhvivo2WHOwsQRNXPHcUPyB4Xyc8caEUdIsLEkxCDlT
oQfd2+9JPX/SyzhT66u8oBvVoqUnCLVmCx/wJM1P6OK8zzKCnnNx6SDMDKAXzrN0g3RKa6NU
cMmUXhvrT7v54iK2wopIL0Yb5jwov/vKRaI47DZerFmoSH+JOrYG9MHhWBNXuRHp9Gt5X7g6
URX9VQL9Cu2FnM9DokDfb8P20JoeYTf1UaBfN4TdI1hBEuW8QbO2ZER6If2zaSj3SrLBtJRl
pY+S6SnJMjSS3vbeUBACRd4Y0qse7Bhj3pCeng9Gk0lPIo2Te8YRxnid1ZcdpaeDEDO9PSxL
4g3tn2LOc6CxU9MTz50wOSG35By4FEeRzyU9QI83D7LvJsxJ/1RmYb+/PTqfx8FCP2bIaDbf
7//xiU/A+ddf/vzz6jZw9Q6lElS3tbW+9giThLVqQlZ7bqq7KLjSeG7SlfRauVEKfRvMkxr0
RqmvgyeHSn7VlNVWS7jt1bQUqT5WKzbeS6+npSiLkmPQWj84JNe7Jn9XOH9aZ5xxtc9p9yLo
e1HGXNJ74WbLmE+xfKC/awr6HeA81/RCehf0DHNHosd+cHJRhnRjMTGFHByF+d2wzPNEFDjP
uvz+iwmgR0l/MS3oKQHNnpiKrOhXT3ql+tFmvxevmgocCrvh9bFhZzqfHw8FvfRj0ay1RPo1
oDwlmYkwP/0Mpx7UFyt96JGhKXhy+hNK+ioOQmCLJdX0wxrzk5rzuqYnf86QS/owRz15ayzx
ZpRDD/otzpN+w2tmI2V6fgM5bwoTnHRpgus91nOdHki55LEqfxaOLumh4VBSDgE/RKQvqojI
3I4VGMu+v0k9yQB3x/5NZ2dXz+so6F9+9fVGMLyuugenvbOu7bt2esy1S0l/jsUXPS11wVJu
UuQg4LcBVm5oKFYsOxboWamn/VOcdK9Qj/kpIjQNUKHWx2t57xNKc0u5ifPSk2dfD7pSQd/6
qZjnc9eejwjnj3PGmXwJ2jGre7FOkjGT3pS8uYGFPr+m/vjlA735haXhANXzSrtRFb1b0gf8
lRGgf+kB+yupmr9IA7DA/CXKv+EqHy5LrPn28itDu7EPsGQqje0mhZFej0zR/b+8zqnUd3bo
O9byw7QprKSvR9gNryQJO+jGwmUfXdJDw9cpCGtm64fFSwkvThVRnknPVvp40g+hpI9aP6Kf
AManCOFS0k9x3AG4PzxlhRaLekNvKrCKEyvfULXujU2JbIMAY2d6aozeKdJ5I08AExxy6V9E
Zep6Ci5zp2eVCo8C3ueTx2uogsdH0BrxfsxVBUX6TcrqcmtoYY+G+Xz0kI4hxi/rh063ddZ1
VhPo6c8RyDJ3uihGuLGj89SZL+nTf/l3rNGfO8m2GQqpgXJz8qGn3MQOTYlK/1DijRn0eC6x
lBuj32CpLOpqasqqop6kekSd3eE132zICSg30eOxdonOys0BqVsbis/z7DHJtfHslJAex5hu
JOjG7BAn0G82rpSb87ne8/qYZQP9Pfk9B4cKei7p3/mh2h7o1PAQcoKgj7DdYPUIaTP792Pi
FYu9L6GWx4tKzNlPoE/qxl4l243OQIjONQuCPqqkv/JDutfndV+s0Af9P5kRYTI9MhCmIkFP
kfR4AogkfTGfn5QMhPop7BbkM1EFAcccvDZsSbjtvKEchJgFJML6cdLfCxbmC0Psv/FKeiE9
+3NEsI8T6q3A4jFx24iU46Ce+rPx4s0oiTd0tPvGpCSIOE+Vuy8nQWKJw0r6GTUuhY/qo4Er
n0i/XhXU3cuvzlvF/PeH9568cPp4W1tnx5HXX8e+PdT0XfDJN773+efv9VTfqd7zc3qI/1ya
sdu05yao3CSW9Nuoj9tJJnq27MAIbxf0WqkH6mWfn4d60m8U+T9BcD1mqYyJPt5Lr8ZiFcpP
faSi55tqn4/zj0/uAiJwKBOBfk3YeQcme47FscalFOp5asrLK162kn7ZQG8K+lsIubFKer+9
0ts55cn2kf7K3ZceXNwNyl9Ekvwl8stbvVkIPgcjbDfWbCznVxojfaRIT6DfutaS6EN8N/Yq
wWW7rIvx5LCOHqndl4PSDTIQhsh6Gd6NJdtNOOhZvIG0g6ji2fpxJFXyKYw/Y5ulAf04Xhld
0UvoDZX0cdFmQnpqvk5OKUdlfzG4RlZIT3ZLEm/iSU9jU7JXkP81kNf5Nw7p6SkgQbzhcj7I
eaXX21sHBfi8ZapU0pq8p9RzD5b1eYI8aTeOSL9Oe11uLhs29MNuXYsRZHMX/+zMmTO/AOpb
Ozt6aNsegb4Rjdgeim/vae9qh7mSzmkCPbbFauUGwZWucpM4NPXwpPLc6KlYR7nx7Dek36ii
Xnb6UXIBJeF80vNJT2OIchNZ0pNyo8m9s26LlKzdj58/384XIHeBsm8kzZIcPjSxZYQeKPob
3JK+3Shdy1bSLxeR7joFvarp1aYRnyofiKR/idNuQkR6iDNIoSTMU+9VnJTeABVEesSaJfgr
MVl17Goy6M9S2M1Ga2AqGvQHV1k3Fj95LNM3BMUbZCDw3vBw7QYle31cSY8ngunxCR/lHdLH
azdMeirpJ5JU+iqyWPZKeFmvwXywpmcxX5lwYmp6qtZJvBHZxl5VYm8OTxZvuKTHDK0bWK9f
opJe92NNjU+6vZLvrY4stV8J8RBw8MY8Jmstkb5es/b2cpt6S01Ggvj+8KGPPvr27U8fnTnz
8OSFus5PXsdejs9ffv31HoTDb3711fde3dzY0/O+gP7G14idV1H0XSc6EFzZetLy3CS1Y5F/
AM+NUm4kfDJQ0LPPkk31nHSmqnjCMM4nPUc24w+B3vXcRI/HemOx0H/+VMlkLTCxSnpc92l6
EpAjbk5gXo1LkURvhBuxWG6wUiwHF6NUS/E5lgv0Js2s5oop5yWn2A2vlLAbn3YTYaTfvx+j
UVcw+noRnKf+qzsl+wXebG8TDBXpYbvZ+P9n73+DosrTdVGQfyIKBULzT9lViKKCUpZVVGqZ
RYJanS1JUdQWSwHZwOEA3XtbvcvL2BTp3nPiHM8O1CrQXcVusctqO+LeD/PFiPvhRjh7Im7o
+TIfJmK+TNxjcGPuPZ6YiDuxe9wf9uC9E8HtOEDM876/P+u3/mYmshDL/NHVQrIyyVy58lnP
et7nfd48Ok2kCLCEvxJGest0E+Ckp8Ng8yfIpPFe+2/C9mt3QZbCbpjneyI9fDWUYuyl3TCl
F+MyaN16WkwGHFeDLAz18wGUnpGeQs9SAn0OWWp4zfmFFjOnp3OB7KAKEurZeSPcNo4BswbS
L9DpIKgeK6Qb3sQT6m/CSmna6zXFJwKvRR3Ge5Ln0S4lzPSk3WiR/okyuwzXbm4R9k+1Os9k
peb+8YHWbixA/cBSb1cknqwvSyYqoN98gP7UK0Tvr0h3uJIAAP/0SURBVCSvVHwsjsCPd/d+
sftLYLVlou/CyBHb0slmXjkIwkSPOq7uinUqN8JRT05LMtWjMkoMWwZOAuav4OsDzPZGFL1l
og/y0hvmykLRCrtS+hwvRegUR48hkhgjSTTSi8gzHXRjA3pG+rO64WCzss02Ceh/sAi9FOiF
wVIPgrV3TLlsN16M/jomA+ZRrjyBvEeEJcbGgtEb1VivlqlU/kqZazY0tqu62s7ofX03JN+9
ViL96up3TM0aXOINgMUf6KHNzNFMWU+VvviOGIzEHkpps3QBPUefpUB6HkCynKJr6onsj5o3
XZYeOj2J+bcEpQ8syTKVl1VYj0ZZAfcpzPRCuPnTn3i2rBfWi5wEjehSuJESjr3BilLoZccs
/iVaL0T6uUpJLmvq/h8vdabP8M4/jBRYczaONvYf6Hz8jIAeUA+s74wUJttQJC0D0CcTiXcq
INfXXwGv/zvxZ/6ia//+rsvKRB+7FoFyA5Lvg/Q/qvWFXgiuJEKfb3XFfmmZKy0/vSL1ZlGW
2DwNE8fzSZadzXdJ9J7GG6vFquyd0/KFs7lJjEXdTp22OJWwekNTp8R1A9dmdaKZQertlP5G
hvt+nZtvEtBrhd5G6Kk11sXoP/KqxiIEwWmvRHYlemAB9H5RxWS7Sdkby4w+wEivAizHMEjc
bqT3BXqeMfUqE2LXcSjM8eE76VRvKAPBF+nR/HqLh4e7ZscuQ9WRS6O8ZzR9oJUeZwBN6YOQ
/t5t6qsiCJcw7xNaTJx+AZuhPzYV0otWWIeh3jl8ipw3N8zpUya9f8STZclcaZVsnbyefqsd
9tz3KuDdJeosLIgMHPo1azffsEi/rNh8zeTMOt7z9d7lhxFLmF8Zbr4U7+jv6mVCL7H+cUek
rCIftsorTU0ViQSYPfR6YGuT+ouJHq6TcvyBKMXaPTfeYcVWLD3iDyKIPwChJ88NxdzsdgO9
oPS6U5b0G6LZScA8Sgb19aD0CdjozXYp3/ZYpdyUDShz0xO8lu8FLb9/jOUh4ZsXQj3/gy8Z
dCO6Yk3jjUHpN0ml3xyg9yb0bKRXQG+ReB+gtyP99YMPqDtqbHRw0C+SfjsBfare2POcX6ml
G/9qLBi93Ujvn2tGoLmJrRDr/cDa7idqSpMOTn8HGQjiJg/xhkMQXEC/lvNIozxEfKs51gvp
MVs2LUo/B7HeZ92bkxPFAeHSS29PQ7CZb7g/VtRjg0qyAuhnjCkkJq9X+g0PH5SpCA4NByNK
CMXnCcvNNio71iMcQYRcUlCCYaxnTd7myOFGKrZj4iwwszDzp29mrDpowyZ2SG3rM1C+pmW8
Ihljb6QB9N0DHbFkWWF/TwRtUxXg3RWQ6Ovb2pp2qiPuw0iEYR5J9GfJBd+/n2dLpUvpe4Vy
cxbnEMTcYATh/t1BQC8zLVm/gZJeQShPWlJF8h0+TfiLNz+TS0yLPVvWMSiEiRrOLpgTFYpq
tE5xHILk9ATwWJgoC3bPcQkq/8ZA+rc+7dMax+ZMINkcoNcdAorQUwACfVmKi7031tExheBh
ezH2+iCPfB09MrovGOhHj/zBI+3Giip+gET69nRsN9DowejTEulJu3ltkorVh6+Ekd5hp+cM
BD+gJ38lVWMNSv8CM8Plmr9XDF5vpCB4AX0KK73g9DSABPPCvYFezS2Zp6xKGYTgyL2xIT2J
+QsK6P3kGzEw0JluZmC9gPp5GjhFnVRupZ7vT5NlMW3Knn9mQr3qnpUNtNpt6bZeMt8Xv8eI
qdlbf8rV2knB5nyE6Tj5wUT5le2n23Y2lUXjkR4o7FK5YU6/FIFA37H7YU9+fX0yFksm66+0
1V+50sTmSlq/KIxfI4k9EY0y0B946Mb5gOGxu8mBj7vzoFhcDxDQByM9KfVclOXZ3mQIIqT/
oOwsxaHp8ErfxBsRjvO2DLZZaeCgf/GBWWn8BIsf3UJ6QDxND2egd9ZiZeTNW/lapd+cnNHN
OUqspljZKqUMlizdOJph3dVYcHOaAm6JN7DI06JZsM78SkOsR7EWuTdBIQjojQWjT8d2cySP
pJtgf6VsmRo9+BpqN6urgmJU2jg9MhBeyBs8KD2AfFncTOJNLgG7XE+WSZaHiH/Lzuhd9Vik
WAZY6Um+X16mASS3PYH+noL5u09zchaA9AalN7IsTaSXecUenF53yc7THHFf4cYcHs5JCALz
bUtcELA4T0K8VOn1JhbWk47PlJ4g/xtB7gnMKZvY7rHX4TgUkzPbp1GiAA6/zVnflhu6/Epp
c+d4Wf1OaPDxjp4vl1pNoO+NJ5OxrseIJ65oq8i/Fr2I2mdbRVvTr9QT/VU+sfkoNS1FiVQf
8CD0AWnF6JYSg6lUVyxwPhDoVVA9NbeWAYMl0FdcJEovZpLYlnNO+CcUaNYoQWyairCr24QY
XfMZUJ7+p5CezDcC5rEqBNBboo3OMIZM/6Gi9DWbUkXfFKDXlylT0nLDbbGiY4q9lfaOKVv2
DXP766i3WjhPsTacdEAxB4MiBMFrXb+OXHoT6L2qscToxwJsN1Kkh5GepJtgSi+d9Hl0SGyS
9LaBH3LRxWFDerTGqjGDHkCfM8u2G6zc4nvzCuSRPJwrxgqSiK/mCfoMIaGRg4HlWEJ6H0qv
YX4OMJ+Tcwc6vUnpfZCe84q1eOPB6W8Szn+74BFY7B5JQuKNDEcwkJ78OLpvFlr9DQ9vjgB7
nVtPIo4OSsDtrm4qovTSbT9jhYc1bMrHF8fY/IR2fuMYOXoyWZFfOA6jfH0iP9LR/3DAxPnu
h/GyZBxRlY87yioq8uOJaEWyogJmS+tY/epsAiiPYASM/gAnB6PPgNJztxQpNxR/gNFSTOhT
Ib3Ub94+SyK9BvoyapmSM2W9os1EiCUpNyelOD9czrD8nTjTDrcSnydKT0ivx8QS0OOKAZze
B+jJeWNR+k0JsdyUI0VNIlip1K1Sktl7A70z7QZG+uuWkR5V2CFEHRDH3w7nDYXV+wH9PmSc
pbTdVJmxZn4i/RCA3tEx5S/Ss+/mlQ34WTf2C4HNRHqZgeAj3hTP3sJM2cW1ZeSbyfVUgrxA
eoC/TkHwRvrU2o2k9E/IU2+bOXJXjBSf0TnGC0B6EVescm+85sjeIYOOqse63TcLDPNkqiTt
xTOz3izKkvNGSfYKztl+b+k133zzJ+/GKkJ6WY8lZm9roMXpYcYWg8bzYgnpn2uNvGZydt1v
dUZ3LDb88gC36oHxtlP1FVGYana2JWKk3JhA/+xZ13hZsnAJBpz+fAL6s4lkWfJiWQWSK9X6
mGEewQhA+nyILxgLHiDSOxyW6JZiE30iKrtiH6YD9Jxp+dan+e+YIj1J6Iimcck3dkr/yVsn
ZSNsTaUQ1HOEPD/4NxrmCeoV0kMdIqAncegiRxqbNnqdYhl/T1H6TZF5NwPoc9Urms5THnpF
6TnSTJRkDZHeFYIAKi5sN7Q5cJ6zDuh7GhvrC/RcjR31DEGwemMdthvfaiwDvc1I759JP0ov
ePO70TP69HptLJDeSKdHayyF3fjI9Ivo30Hjq1blcwST1ysXTvtHDu3GKd4EJ5sx2V9eppmC
3D2l1z1i+Vi3jGxLknjumkDvzent9Vh7SfYuw/y3XISdhXzjU421oJ5TjbW5nqGeBX4jHQGX
Bt4jZtl0CSr/LQs3ItNYd1PZGL4w4sBcP19rhYfVbYrTZrZWjLyWa7j9s6LW7p5ofVMTBRE3
XUHOfM+XKMUWadNN60A/kD1CQN8FfT4/Tu6Y6NloxZ9bh9xfCphHPfRi9CwaYzEX3OWv9M1B
oG4p8tywcoNZsYLQp6T0pN9gJvjZMtjoRTUWhBsxCEJbccg3tjnhxyXMrxTIM+uIUHFaINqo
BZzXSE/ajfwL8Oo7+qV0EsKnZboRYTNGTW0G0OsXpAi95PVspBcYb2uSssM+d1VxNZYTjWm0
yCA6pGR7FIA+VTXWqzfWqsYOUiJ9GrabvDSM9CrXbBd9NqZfGnc3/wHE5OIp7bIElPsD/SKi
cDSVv13sYadHguUtI6pYYL7dTb+cWrspXqaZgk8NpFcwP8uajV50PrBRem+kp3rsI12PNZB+
7pZQbSSOQ6h3ziBxMXzOqrclGHM6jq2RSpZlvXurKPrsFjl0lPtGQr2g9HpxCOaTSY25wxO/
C//o+F3fpNX6SopN1eEiWt2P47DQUD5lU0UMnhki9BbQDwx0QH2PDMBT30tVWUTSnI0l8s9W
mE+YcB4BOGRmT6h6qovVezdNyeBKrsXGCt/qkcpNGkC//8AnhdfOSkpPEjqKpSpvEkhvKvUG
pb9KU6BpTe8Qr2CbaP4ked6EeaXe0KlEAj3Xe/Pdrhvuj/30bW1R2YwMxE0A+hlFB0pbLISX
Ir1k9HZK71RuBNAjtB6/oOEigwa2HxwaHPL3Vx48gnR6oxrrIdKz7SYI6KVIDyM9OqbSE+l3
sQ1r08pkG/iRFzp9aYmEerTGUqqZB6XPzZnjnk1C+vmctUXvtilKQXBSegfSo6XqSQqVvphm
Ct4UucVYTwnQqY3KmYFDlF7FFQeoN0/E/FhjcZfs3COGectTSUVZWzK9p5ADGL9hIT2PJGG7
jbWI4vt30DKE2wR6Rnci+Qb2f/OnG+W6ALtSsAmDbdbqpqyeKMDaRy3Hi84xzhe1DkTQ9IoY
YtRi2XOzt5vgX669Ax0A737yW+7tgRSPOYLIM7sWw3Apa30IWt1Wz0AfZedMP1IMdjtpvUZ6
3TQFLz2VYqXnRgQUC+UmTUoP7YYoPcF8xQcQlID0NKKKSL3NfaOQvoidFfSZGJHPfk7w1uEv
LJyXKj0NJuccetJuBKWHdmMPr9QqDkw61pzwuQ38CPs81CYAvU4/cBF6yeiFnd4m3ThCECSj
Z5xHipk5Vgrs3rca67LdeAD9IIKKA/2VCujJSJ8e0OflVdNn5DWLQRAHiPDTD5dLbJ+dvesC
+sXcZTRSqfUEqrxX1xQTfPhw5vyBnuPNKNnsRSqkJ0oPhyUh/VMaJIvlNTXcTek9OT3VY1V/
rHbUz4ki7KM5K6P+Bn4OVOnpl5xqrGV6D5xPNaWEcZ7qtTbthjQdmlsi1q09lnt9uDJ02/xs
uU2vWRkebD5zpoi+xOp+GKPEso93NsFzg65WKDcW0C/1RuC56aTybGt/PoA+EYt9ei3+qcw/
EIfZ+1DKyVwPY0o08Tai6o/1HOgCZP9o0+q9KD0ycli5eSdqK8WmB/Qs0pdRcyz53BnneaYs
ooWpJnv5sn167M/OSeM8PhDKGlMrTn/3rWGyXIsljV6ab4jSK6AnSg/txu2kh4j09llxAY21
CTkI4QO9niBY8xuD0DsYPWk31iKKbnPSE9AfhGyDCSSOTBuaPRJQjR2k3lnLSO81ZWq0HWll
lu3GT6SnDASHkd5XpN9VvZ3evuLwz9Mb/xdyROqqTC1WGQhSpYeH8t68BfKYesohCHYzvaHh
kMHSpd3YKT2VY5dTIf0yel9nCeefUhOsD8yD6xOlp4Hh3hVZbbOksEsbpX9yWxVhBbkXixT7
4HosbSWCcSxjPUaIO9yWJO84LZYWxedIHFWutav0ktLvMIqh0+UhazZ/LLHrNTVHqw4B5Rnm
FdR3D/Qk23Z+/HFTfSLSQSZ6Af9i9fbE4bnpZaAnkT4BoC8ElP+Feaz+BcwvbW2ILybtBpn1
hYD6Y5cF1Bt9U25K/4VQbqhbiuPQLh/QhD6leAM3feGnbKVHdqVKKiCoT1g1WRPpj/OnmHiP
zhH6Rl5WNdvpvKb0MN9ISq/KAEzpzUB6WY399NP8/CYlxdWE/KZS/XjjocLxiCP6tKXiiRXe
k8FS6fE2Ru8S6bdvJyLPOO/UaQaH9j0wb7NFm13/PVISAquxcOTnpWW7OdKehr9SivR51S2v
LaVfvSnmKAjzzSMZdkOtsbnFty2Mn7+zvLaIWu2sZbv0EOnJYOlojnXJ9JRshikkwYspPTko
eflOF6QS7R0H0nuQes4rNrUbdFsRnZ+fk1FnEumJ5Kek9JRlPMNIz9NIJOjbtBqbC8fZQ4uW
KpF8Zi2Ge9xORpyndUZ4WEO43OGPe+x6zcrw/cYzWBrlJaXvHuiCh37nx01NCa3cKKB/9vBa
LBnv7eXgm97CMmgzBPRRw1xJAPH5KVB60k/YYRnTUP8lBByL1bspPSk3NGmWFXqh3PQq6SaF
l56LsSpsuIwmTqnkMSb1LN+ge0pC/d8op83KcJ2G4T0CmYeLXDhvcXrMoyWzvmy/peg0L6RH
fxX6dEVWDlb4DsvwgV7Xc8SkWCu7kmPNLKA3MhDcIQjXKaESSO/OtYFkbxPpG5sNr+X1fWN5
YymAHsbJYH+l0G7QMeUy0vsZLAH0ry+lX/1OODsKSgD0EOIp7GZHbo6h1jyCvUaQeAC9ZvRe
Kj0ZLJ+6tBt7QZat9KmAnii9jDq4Za/A2sqxdD5YQD69L6mXs0hIvLEo/W1KwIGao2DeIvXS
aRkM9pyEgLEkbJ839XqN3LyFTzGWHPS2mAS1HcT7b+5NGE1KU7WIxQ1t3RyZtM4ofKo/WH28
iFHehHrm7s+WuvKbmj6GdFMWUcqNBvr+RAKeG9RisQaOwUZZFv3wYxlnZj77f/2LnW0VcNKX
QYPJN6CetHoN9S5KzwMI4xhMBWWd8o1RirWAPlXXFJQb5BTA2olMeppAYgyfws8xqdQz0h9S
TpuaSr3XZRXWIds4K7J80SDLsTD2yBmzTk4vgP6UAvrwHZahA/1d9Vqmtls4LycJ2oHeQHoy
zdsWFBqaBEtqvGNC+EF4LU1G//Of24CeZoUbthsvkd4+NtZvyhR1TDmN9L5AX9XCKv1UaB/L
UB94G6cWs1D/BBkIiybI383heBu5cB54EUjpc3j6SKBMT9rNvZSUnsaE05q9F5hkSZQefD8l
0lNesaL0cvrgXVvzlJBvZtOpx4oYyznGedEn63TWU1aCj8VSZlx6ngZqjXJoad1CeO95cW2D
6aFkkD/EAC8WvjWlm+7Wpf4YA/3OZKHw3FjaTWsPEugjAwLo9/Ykm943bJXOl/DnH39Ik0lg
lLRDfe8XUsBxUnpSbojQA+jJRE9xaBgsmB6lV4T+HSbw+dewYMaXccIGqQenb9SaSp2VRHNb
nAhrDrllG9U0xW56xOJQ0AJlpwlnDydYOpCem6uiZbrAHu6l2mZIN/rqxF6KlezeZPT+QI8i
LFphaXCsMtNbYH6dTPUGtv/v/2ACPWw3Pr2x2klPRvp2K79yn49IL4DebqT3B/rmFjZlqUp9
eJ/RcB5ZVIlqKnMNQX529o6su1rQjoiEHAP33eINGSw9tBtLpkdBFlb6WzRCNmDdk9L8PFdk
AzKLidLPwo2TCunJTP+II+pvi4TjR9wsa4bUM9SToJNSvCHJZobbpG7ZZohb2Qi+2fXkubkB
ld51GlgzFJuVmsnQHFzf76k0kw3obT9a/ct4fMDAeSel7x7o7ReMfmdFITw3QqKXlB6eGwTd
iA6q8Q//PmV7/7ZffN4GqAfygtWjJIqyLGn1CuodlP4LzKViEz0pN/G3KA7NBPrgxBuYYli5
EUINjfDW42NVTZbg+HKLgvnhif+f9fmSVdijvZcvByG9AfQq70Yhvdk3JYfK6qap0J0bYTP6
bfrixPJW6q4poL2W420ivZ3Roy+KMsyEk95KNhaAjl8hC0GD++i2Xw0ZZwGk3eTlBfor//CA
gN4aG+sH9Nwa60ik96vG5lW1CEo//MdwgDj0R30hjvWCp1KVv53zAhqNK8USnbMYEK6XG+gp
4dLVHOuQ6dlKH4D0OSrRZuYeG28CkV5S+gCkFyVZnh8LpKd/kYmgdBwn0pPFMnU9VoyiEgKO
a7EU45Ndz81V8/NGNZa3Xqw0VJSagr6UaLm+42Gh3F53pQN2e8vXFyoq4h2tFp93Ufpnjx8e
SzShGPvxzvr8/iX23GikH4iguAlz5aWvPv7bdJ/Wv/77nYgztlh9D5ktAfWg9Q5K/wXmlQhC
T6VYmOiJ0KdJ6bkUy0Avm6QonwZD/1iphwGH5Jy3r3W1K1fpcK3R3C5NlSstb/mgPG62bDcw
WHKwGSdYqsGxpvVGRKC9U3ZKXzqE3UgfNtDvUUA/6RRueD44Az1TeXs19qDpr8QkQcq28RsQ
bgP636yu/sYA+usE9IOBtpsHo7uqzLQbP+3GC+h9KD0BvVDpNyeZLt0PVAbbqTCPkoVZwnhv
M/0OqsZaIr3XDBKkI7gNlnakL8ZQ2TlyWnpSevLQ0yKFHtFmqZCeKP0tMtj7c3pGeqrH3nxC
kZd2B44N6UHqZ9Kh9HcpxlImJnhAPUw43rPE+QQhmml1ZMJceYPRpVRTUB7KYIrvnk/YHZS4
fhsebTl8/MxAPFZREel5ZgN6Wz22uxUzpJLso9+5852exxrn2XfTWwifzVef/9sMjjXe9C/e
/7AMqrli9QcU1NspPXtuON+YCH2HUG4MoA+g9LoUi/HdlGUGMyX53hFTz/KNmCg7IMdHwTev
DZV4ctsmBPoPdwfgvIi8kYE3jPSM8xLp37bFFZNET2eYi3pQR9iN9GEDvTUF1w70jPJp2m62
o0kK4TYPJJ93iPSUiKAZ/cH3VlffM7WbQYftRov0f9DaDfw07XnW2FhfoOeOKVuqmd/gWGb0
VXRs1NzJ9IDfMtuLY7umctmeUW8LN6Nq7Jp5i4vTk3bjDDZzdsiyld4T6Hk2OK35ezxTUAF9
gHpDm4n4m2CbJSnzAuYXrIgzt3xDFkuaHxu4hN1GD5f1wnri7k6LJeM83yjwHlTe5noByocw
N2q2r67A1vBK7/LR9sbjZ44TuC/FEm3RLqdyY4r03QMP+6/BdMMr2TNgAX0RYg8OfPXxX6/3
GP7Lj0+Rl4bNltxCRaxeLWqaAqEXwZVnaeIIl2IJ59Oi9KT5MIsWhJ4yDy5/QsPDEZtDpB5I
r402K9Mj5lVUsbzAaof44k/ohfFGAb2cK6inC+bbkJ5GUvFf1RmWYTfShwz03+lS7AMH0AtC
b8XcmNZ5aPIGwd9+kCqxcLpTb6xTuSH5HkOmNLY/Wl39VwbQb4d7MpVIDyN9lTE21k+7gZG+
ytkxFcTod/GkqemQLrvX+1nK4H6L4rKyVDVPeUXewIsjIun93PRrPiK94bxZ42QzD6TPeSTJ
/O0ckH2aKcg5CMHqDVH6m6JnNlioFyiPYeKmz9KF9LepHpsi8kakVZrBOB4CDun4DhMl3UkY
6OHFv2mn8is1DSMbfTW/Lad8cspedSWWOlgNozxQnpG+qD+ZbIu5cd6oxj573NWTANBzc+yV
+JKS6Emk7/xQZxFncKQZm277GJ2yAup7BKvXWA+gt0z0wlsplZu0KD3Z7wGuQqHnoeDwW4qJ
skzq85v1rimQYQfieW2rlHS+COKLP87zbziWnhBcTAlXIwXxPYoQBqcXyg2dXjQTDjm6KGSg
13EODuVGEXqSboDfctSUNtoYQE8qPEVVoifWU6Pffp3qtBLbr7fTO9NuID2AfiyF7cbpr/Su
xg6JYYL2DAQfkT5vFxj9rjF2aL224s3qquoOMVLOnMOmUI2VScU+bVN+Bksz9GYNVvpHBPQ2
8UaZ5ucJ5WndhSijgd6f0xOll22zAfKNUm0ePYGMEwT1VI+9EcjnuRuWKrHmVi6od3dNWTg/
P59bZyuJDjeUbCxB+O6fJxpKzUgDUW0vrT4NfwzqrgLmAfTdHcm2irhTuGGPpTTeQLnpj0SR
dVOP5OGmpmiXBfRF3a0PL+x838NLmR7q/+v3P0wmaLygyeo11oPQ76ZhseStVF2xDwWhT4PS
H9ClWKHQY1yJmh1ONdmB+2rv1EzaO48X5eVPNSh5CqDXhJ4Qnk8p4lJBoL6J9Brooz9XVDhk
oAgZ6HWtwVmKFcINM/pUQA+nPPzzAHoVSW/XbhjolXbzLh1RJwygJ9uNdzVW55qdJ39lymrs
EWb0TqD3pvSQ81uqduWdZ/HmXnoH+ZbcSjoNhmWfrDvF8oW9Gkveescig6WHk94m0wsrvYn0
y5hIwr7528tauSdKL3IQgjk93U3G4Pgi/W3yV2LNc2U2EOlTRN4I2WaBcNxxOnBgPXT8G+aI
Ej43gM3fLbGD/Mp0ZfFGovxNPL5TqiEi3/7uewgli/cOdBPES5w/8yyCHqZIt0OhN3w3RfDc
dORXILgymUhi+ndFjyHdFLUeQ6JZJPrh+xm/gm2/2PkVV1kJxS0HDng3GWtYvyHlRpro5Wip
h+S54S/tsPRT6S9DucHckXfKzjKhx9WAHij71jGLzA9P2Cf7/U4GuAx34vxAOG+LPnDxe6Xc
kN7/Dv4SSUUK6fEAOFVwZrGS6HE2+ErXfsNFgHCB/oY6XTW4hBsp0TPQK0rvwegplph9lRDq
1YBwp0iPGSQK6Dnws88EeoQg2CLpXSL9vqGxqnYz1sxbpD8yho4pl5HeB+jbW1pwUhjjemzp
6+q8oV05K68suXvKI9zM3jLlFYVA2s2LRW+oV0GWL2hIOAO94PQ0SpaWJvMC7FGWfcTzwoOR
3qD0PuoNzwgXTVKig8qF9KbRMrA/VhhukH2GUGO3lm9iPdVjF6xxVFS/vTVfUmfXUmoaNq74
+kPOSF3DtEuqQdV1sPpkPFqxc+fnSCXr6AXQS5w/fqaod7wtkehyeCtt/spnA12FFeDyFWWx
KA39jgwYlH4gEoHnpqu1e2D8Qz05MDWC/eK3X0U6MEYWSE+FVierhxJPUK+UGy7FclesVOjT
oPQUfwCJ5iwp9BgJrnAepP5vrg7qS51ppx+6T+6+ZkJtIvQYQxK0lHJDbJ7EGlLiBdKD45Op
R8TeSIkev3rnHdG0ghVuslm4QK9Te5zKjST0ktH7224gwSP3gJR5gfdeIv0+jBRUIv2/oYPq
35q2mwcAejPtxhV3sw/+SthujGqst3ZDGQhpAv2uXWD0AHoh3mxCYlHqj9K6tyiXAmWdN9I7
q7FuSo+AyxwMIfFaOrH4iSzHEtIv35Uw/8Qi8wLomdKngfR0KaCSLT04PVsryTpPDvo52Ssb
QOpJvFHRxU4Nh0OJOfCSmL2Hlm9APW2rW6lufPPtjjqH8WW6Mnfdb5N5x23zJRMeYjwXXe83
n/zxYScGd9MgQBjh22Jd3RrmjxctIcQmHu8lLce1hHRDnptYGw0RjMbjyTakIHR1Wv7KvZHC
ZH5XFwfddHe+93lAs5R6xv/p86/6d1NYPAqjAuqJ1AtfPSJyUJYF+Ua37BePSbmh4EpqsOJS
7MMvlHKTUqVHKVaa6LVCz4x+tzbNoyqy5tj9tyXNOXoJgMyCDw+cCliiFMsAfhYoL02UEumB
/ZLTm5tpK33lhrz5fg8SLtCrS8bhKj9GTyI9gFz4K3XLlEXzRewB/dpXpD9oAX2zeJktBtIj
nTLviGdvrNRu9j0YSwvoz3uE3XjYbhB3k5fXXg3XTd7YkSOMkmE7p0I9QFZnZPfetFWUNYqv
aJ21V2NdSI954XM+QK/7pkSyGcF8DmKLPci8QHpS33leeDCnJ6uODrd0IP29pxRHjzV7+6mw
WPohvUXqKfDMU6UXso302YOie9tzNLjTtuKH57WT03bFfLihfAOqcTPPaysL3Fo8HYTD26tP
93b09Hd1dfX3dETisWgbU/popLNII313B5SbSOGAB9Cr7lgoNz0J1GHrMVuqI4ZJsMmOHk3p
u5cA/vGHoi2WMxDGd/4iQMX5x/dPXWjFAobv7xJQT1PDDQFHxp0B6pFpsx/KDY8cIUKPrtjd
Xyx5IP1D96LTCNtrojxTSir0+w98ppX5ldKJbx2fo+9lEbamOSFi65nQBwK9odxwNywWc3ol
0+NsAU6vRlGJ80Gbbs8K9XMcKtAHKjeyNxZc3UO6EdVYOglInKdIeuQRC0bvIdILaP+12Fe/
tlVjSYAPcNJjPjjZbqAM6fXAuUTYTVV1u8tf6andEKMnoB8be8A1r9dZpsfuHJGHYkOf8tNb
SI+WKXs11iXTU7AZRk8FijcvHrGVvhhVWV6GMm+a66k+i9JsSqSnPlodVm9Heh4ODsnmNo0Z
FF1TavnrN2Sx1JmWFuTLGeDyBkJ9v6KtgHeSee4Wu50vww21LzsU8GZueV2B49yhJAFk6jZf
7Yhc6MDqoQWYj8diiSimh8A7E41ppIdCH6+o6OjxkuhlNRZG+S/ZRI/ZUh0oyiYh80cGdMfU
w1iiLM6BZryeDaC2W3/qc08V5xe/jXbuJZjH2vsFQ30PKqZxH6jvEiOiyCJDJnoMPNkPS056
lB5nCCL0+QntrQSZb63SslZNwR4XypbL326/9A6dHpjQM9AHUHoAff5ZEms4+hh3UI1RNDKc
u2/ZeoOvt+VmuEFnB/wPYSJ9qEDv67mRE2O5Y+oj5A/72G7QEsspZnJAuF81Fm2zshr7V2JX
/dZuu8kbM4HeLdKzkT4wBIFyzag1Nk2gV4weSM9JCKWhNL2EeVjYH/uG1BFrKtXsKctO6arG
uig9GSxpgmyQekNW+pxZgfILymbjbqCi6ixuTYX0FIxj5NVbUM8DY6kRVkyTvUP2SkXpA5R6
MtNT4pkdxy3ZRtwO9w3NmvVZAPo7e+ocmTIg2g21LxEvP/NiZKKyYGrY5acRID88XUAO8GFg
fEQugH0EdD42nsBMkApC+raKCNpgRTG2dzzalujsJYnepd0ISk/KTfwKz5ZCcGV/fqytKRrt
V9rNs65ElMbFakK/FEEa8TvXeiJf2eLoV1c/PhWD9PKjAvrWvY8F1BOrh34jtXpbBg68kKDl
lE9DeWbUFQucT4/So81KBCdQ9ysT+t3NanAU9o/HVMZ7UrUZPhllC01aQM9FVsJ5hehcdoWY
Y1lvJNF/mx394nG1dhOq7yZUoNfKTbuXciOTzWjyNyO5zUnPejz4vLDk0JIivYdKv290VIwT
HJTO4380wm9cthtXrtkfXP5KT5GeGD20fEfHlCejx9jBlup2YvRjY8wLXmM3vYD8EvlWDk84
nTeO3liPeiymjzzlWeEBSE/ajVhPgpIsuWkqDaSnblpj/pQaNyVqsDMS5oH01DV1V1N6f6hH
f+wNB9LzeFnb+HDKK/adSFXiYW8sbahF28c61syLvtpK1Fl98J18kwWTE3134Omhw68qQmQ+
ciFyAZI3YD4eJ5jHovHeO5tORXuegcMD6Lt7kBIfWyJC76HRC6Af6OyPQfRpuljY0dPZewzj
Y9sSEZWC8Kwfp4/IYw30vb3xirYr0dixnmMxWx79312j0VQPB/6PktGD0yuo79FQ73DgHHuL
48wY52UpFkifDqXfzxn25JaPilLsYUuyQUqr+x34TnptaqoROczDSYSyLxi9L6Vn5YYTFcyU
BdGmpdQbqshCvddKfv7bSXVhEepEwTCB/k8pPDcs3vAcWA/bDc/+prhKBfRUlvV20gPoRTUW
+QdiNZoiPVVjAwMsBxFUbLPdeAH90NgYgN7VMeXppMeIKfjoBdCP8afx9S7IYo9uk05L1T+l
KT1apsw8S3G7zWKJ5thZf6CHTv9C22we5bDL0jfebBkAfod+m4LTk8ZjjqAipGehhrQa+l6u
O9Q1ZVF6X6SneuwjcyYJ51o6lXtQeo8hs8/LPWTz4YLKkgwv87bN3NszAnz35e+sEpZOTdaN
vJiXTbh3eTTkyf7+flJsCOvjJNsQzFN8cLSt4hSrNx29rRgtcqab+HccCj0tT0pf9GygvwMm
eqB7YUf/w8ddvfH6+mvxJUHpuxFdmUj00BRBodwQ0FcA6DsKC2Ofm3j6Psqsl/cjD00DPZBe
QD0mSEmoj1GupTBbsrG+ED2xlDdJk0qoK5aUm7QoPTQfLsVGcdf8a/3VlhOptO6WG+a3KdXm
YITwmWaUQNnXyo0f0lttsdhcx+l4cXrgvAR68vJ8qrWbDajS+NKGMIFejxz5zVFfRk9EXtJ2
e6wZkBu6jUXoIdJf19qN2fsqoy3pJuQfiPVzq1X2Omw37eeDq7HpAP15MtK7ZkyRdu9cqMYS
o9+1SwC9KMhOrIO4ba27fKOOx4K+fzbSzdAytWzrjXUhPQWbrfkjffFTWX+9OSe89EFIj8yy
W2zGSYH01FNrhlzeuydrsHNierhCeiel94N6Ghsu4+pZmuG5gy6hxkHpFwHxbt28Znqy/G56
b+0Pt5b3lNfWTTZMBbB3yaaGpxoqy5/P3Z3HlzXhigrpw190PuzsIqxnBScO2QYwjwVOT96b
nTtP5fd3Ap2LBuJIiO8QCr0Xpad5sb0d8SRM9FBuMFtq71IXxseWRTtEORZzwTE5kD03Aug7
MWKqIhmNRQDVX5mv+UOYZnCeaH1mIT0PlhICDjQaJeBIVk8WHDxGfgJCCvLrWX0h5SY9Sg+J
/q3423TnRLxRBc3jrNjgGQqqr17PXUwmOa8mKYFe8HlfSi+UGynR04lBD5OiWSQGpwfMYzOS
8tmHo7WbMMePhAn0Kmx52Ee50R1THrYbcHlo9/ZJshbQ+7RM/Rd1LP1XjmpssO1mH/yVu8yO
KU8n/REaD+7umPIE+qrqZg30YxyFsAkzZNIDj5fY6ol6Qxv6aOKUWGiZmgsG+sW7bLD0Em/W
iu+hDKuWtNIHIT05LO8x4Q9GegpCMFV6mTk/L2DeQvo71DhlaDeennr4b4jSox4r1hz1UNF4
WQ+zpWii9SuNQqwJaoba9u3CvdySvvLaSmB7qb8yY5VZSYZvqKwdWZz/j475hRytcI9IRvuz
gYHe3k6y2/QD6gsh3ESTwN8k2HdsPEnWGxRUvxwYGIAOE7VM9F4OSyg3hVFI9BVJSPSdS63P
Hj4cr29ri/UyoV9aipTFYhbQt/b3j5dVRKOxQoB0l3nkRQsjPft7bUBPlJ4Wxn93Heg/Jmz1
ymwJJk5FWMwMQc4kAT3H3PBKrdIr5ead8dNq1Dd2y1S5Z8TEshTna1oQKo8ESgwSr/iAgF6V
Yv2RXnhuIMhrSd9AekOn545ZrfC8XRhVVxhhzq8IEeh1QnGBH5/nwbFg7u7eWJgpeZqUOX1E
pCDgEsDLdoNxgs0/tw6lXzdrTg9TjU81VvkryXbTbrPdeGk33BoLq2YaIn1eFVLNULiVS5R9
wjxdvwR6Z3RXRXZq0EAl0d0+TtAz8wbNsY+EmGNT6Q2Un80pNqz0QUgP9X1BKDvBSE9xxYrS
3+NoNKSX3XEPk2VKr4fJ+rdPkcXyrsT5R4zzHnI8qfQLJQ2e7hci8k9m5+/O3X66nPt8D+C8
vLZ2oq6uEqDeUDA1DVz3ldwNYFf8HSJ8XXnJ8t3/CPruP4+W+1g+Q9ZY68DAUm8neD07Kwno
mdID6KMcT9ZWEYPxMlJRH83vlN1SnpQe3VJxMtGXReM9/Q/RKvVsoLCtvkmUY7uh1CTjER4X
K8yV/T34UwT0+fF4619bh9pfAqn7Hy7tfYZlqPQC6eG1tEG9EHDwf0BQetY0e5CAXhL61Cq9
UG5iJw1hvrTSQ7LB81tQ7UsHO6IXMUOcIuWB9JgH+Panb2HMYCCl1+ZK8txQZ9Qnx9ycXowj
l8q/HEmie6Yy7idO/9MbItA/UcenNRTchviGv/IgF2MtYIfnEpMDDd2Gf4+4MW+RfnC05dcl
9tbl1f9c8m4V83quxj4w/JWuauw+MtKb+ZXeuWZHKL4yDaBHD21VVXM1Ro6rJa4WX287vTik
tk1I9oGUdCnHe1Vj7TI9NcfCYGlD+rXiHEo5oDV7rxidU1SOLcYYkhTqzT3hsEyJ9LSdoPT3
nogZhLNPPAMRyIdzBwYcc7mNlk+I0s+weDNHMg6+91qUUamtZm54ftlbaoZLCxrqyvueoKeW
PD+IcAhY8PmQ5+YoRZUBdVtbCeu7ejqg3USjzOgB9OSnh07f1ASEjsfqmxJooCK53lu8KWpd
YhN9G0z0PV1IT8A5pCNZDy89NP6i7q6uccwWtGqxAz2FEugT/R2tH1qo9DkI/QFWbgygV5R+
716E2nzJBhyL1b+DqgIGigN7aZw4TDdSok+D0hOhf8tE+ZqG594A+Y10zq8cvZpAzNlF4Hw9
hr8iV14AvcZ5z3qs9NxQxo3orsIEWkO90S2yok1WAD6bcN7SfaW2MLX0QTydLUMEeh213Ogv
0bO/EsjrtN0gsVLQd2NBs/dsjh29OvLvvF/qfxi5eh+hZyl6Y/+wz+Wv9LTdEH57MHoP7SZv
l43Ryw7Z13belG3n6g+DYvX2cYKeOZYLwmBpUfoXOar9FdEHIt+MrfT4J5VMD8iel8XaQE6P
CDSm9E9knj2ii529U6zU06ypebJapoB6ctlQPZaHTqFT1uG1FLBPlJ7rnxu2hoenpxoaKutq
R0py5+b/L1Dgv/kWRd8FyrD/5lsH0DuT1HbQ06g6jH4oYD3AHsS+t6tHUnoo9InxGEqzSXZZ
gsvjm/rx+MNWMHKJ9c5QenRLKRM9KzfE43tB8esTnbjPs67+RFnHgK7Fdj/uABVHzTdWmOjq
eBa1jqNThYiS793LQO+m9CD1bqgnNs8MG0JKND/+1uUvKe0sHZV+//5DBpf3n+OiScxwcyEU
fQA9RofwjG9Q+nc4NyEQ6W2Enmu3AHoJ9SLzQOr0FFHPqQiyVfatr9ThMpkOZK9vmxCBXpkr
p42h4CaltxLpIcjb/ZVItsGIWMfcWAD9AzVNUIn0Bxt//j8GvvBt//7np5FZ5m27Ublm7K88
Etgy9QA+evgrYaVxSjdeQN8OoFeuG6L1eYIH963vPdpi91IdgyuC1bsCLN05lqI5ViE9UB4U
nyuwT9SYQSA9WenToPSyacrB6d1hloLSPyUJh77zDC5mpCfPJSh9KlKPTiuqxwrZRtRlPTg9
4FeP2lkf2NeAtk9PFUxW1paX7Cmeu/v/5rB6A8JFuM5d7tailLSAxSbBzw4fBtRLrH8Gd2QP
l2MJ59F3BKCPJqHeQKhHnMFO5B90LQ0wVnvl3XQvdcWRkQMTPbqlSLkhHt8fbaovg0OzqLW/
JxrtaLWAfnckER1PRstikUTPpWe9WpjYFosc63r4BSs3npReQX2/YvX5+agfA+bb8AVKL0R6
ykVIqdL/2HjQkMQKyn/n92lSbYE11QfE6CmMiRI4D6D/ABwdSWgGp3fmINg8N/BwEtCLkVOc
YqYd9gB4NZBEjxgsVAPFQpwRHh7Qf68O9AZfQs+TR9gu7wL6BzQI1kboyYfJLF9r9C2//m1a
kd1//KufN3u2TOkQBLLd2KqxHpSeFBmvjilPRl9tB3ppp6/5aSD9qsHqy3c4xgl6UXqaPiK0
m9y1HNjqxZozhslK7SbHoPR+JkuRg+BUb9xIT557CfN3n2q53i3fUBDCguifCiT1pObfZLfN
Lem/8YL6b755Oj1dOl1aWjpMqwbLDfi4cXgYm0xPA9ILCsDYK+smasv79tyZnUFNFVcGPItE
ThoHgZfJCYzp3KdFzJ5Sdlwzam2wT1Tro+MAeoH1pOE8W+pkSp8AnSc+z756odPTuhKP93R1
9gLrSWh3Yn3Rs97+GCXRl8U7oNxI93xvrL6+IoKTQ2tHjKcI8qQpXD88e1gIc2QZAz1sPXv/
XmHsL8hbuVsoN96UnqR6zeopAgdNrQB6ibrQbj6NYHCIhnqVYWmNCRchlo+btxu7f6r2G1/O
1Kdo6f3HNI9ETH79gP5ik9RuKNMsCOllKVYE3rNyYzB6Tj2QnB44X/EBTRmUQP9W4VvStr+y
4oxh2DiOFx7Qa2bjI9GLnGIG+kHRMoUOWYnt1zFrxAX02HDfoCXSV2cS2b1tT7VXCoIYM7WP
jfSpgP78KHVMuTMQPJz0PEqwKk8a6YVSz5y+xqM5Y+Pey018JA31K9O1PiK94aYngyW0m9zc
Yk+Ul5HFyD+YfZEa6QnAde+spd64kV5weaD9HcNo6SHfkL+eKX0KqCfqz1VYc9ygk9XPIsVS
lGn/43/87//Pc/9f8funOcU4xc0vzN6au3frxre3AMda++EktLuYNiuUHxFweZeHzOrkBAn5
IvtSngLwhzyGkfMWEu376JBrETgvwR6ZZJ39HWSlH48RzItOqjgyDRBwRkXZWGFPf39X50OJ
9TYJBz75LjLRN5GJXik3RUV74ZWvR7TZM3hukGhGuo8E+q44fD1RwHIkv7d3714t0u9EKfbL
HyWh96H0DPUUb0OsHg76syggM9CD0l+MyqRhniLuZ7xpbbGaX9GdPuFdfuUPTZ+i1NuLDtAi
pEemMUR6CfSk3byNiGHVMuVhsTSVGyTaSOVGy/Rv6YAzniZLEhS0GzojIChBGyyd6Zkb95EO
D+jVWarGty2WIyyFkV5UY1VvLGaNDA56AD3w30ywHD1Z/h/S2RP/YeRElTejF5R+374xqO9j
qAoExt0Qo8dmLtuNG+kpj94J9BLpfyKcfnX1hipc4SM0726Zsrvpge93cosxP1Zy+eU1V5fs
2hqn0pNaH6zTU9MU5SCk4vRypPiCZvMC7t1IT0EIs6qDKoDUS4umpvPKbGnHemb8Xou1FqRg
+sRc8l2QhkNV3rt3aWjVI4nXHtoNnQ3oVAAXj8dSN5KZo8bAeeL1Z571dpHxZhyiTQTRN+il
wo/j6HXlYd9thP10K2h9LyQcctdrXl/U/bgnwib6/IhWbqgGm0i0JXs6W+G5ScZIrBdA39ra
D1dlPJqMxSMJsv2Mqw/rVx3HDrC3MpDS02TwH3sfMtQDdqNcG8WicuzZ/Dj4NYUNC/3GRenP
VFt+eXSm1wXlTJQomD96+kA/Az1noIHSN2ntBr6bfInePs4b3RYrCL0F9FqmFy2ykP6FmUcB
PZSdqLruCK+xMjygV9dCU77mSk3pkVzGAZXKdgNz5aAovDqrsQT0tlyz9ndL/lMQ2P8bmG+O
5MFTA1e+XhSJyUsyeo41swUVeznpx0YB9Hlu240H0CO90gX0Aul/Ap1TandbUD88WeK20pvO
Gxgs9bqb4zNDlnw3dyi5OAXSkx5jJRj7cHoJ8zNPzLYpH6gnBH+im2X9oF50XN28bUbVS7+l
ievsw/RW7yXXBxWXgZeuzRjTcSv9S7Rfs3vJ8xXZJygnCWchCOjvEHocdAH9Eow3FIMQiSDK
klup0EkVq0BoMQE9QJlpPsVcsoRDSZTAekq6QadrJIGRI2yi18pNUREiKysqCpcGHgLoC3uL
FNAPtPZQESBRFrvWkU914P6/FYfO3xZG+r9UpVhflV55LQnqYY9EWhprN0Kk5/zKwkiHnCxr
99L3HpI1MSGaTU0ERsZpmB9ulCjPSA9Kf7bsF+LUIq30LMhY6o1dpX/rLZlQrJQbodBrlV7F
3ogaL9w8bM8XGs9bhbrlKB3iuq5tQgP6H7RE7w/0zOhhpD94cJAxXQM9megl+pu2GzB9m0gv
26Kaf/0PnpMqf/grttMfHALQ2yLpHQZLabsxE+m9gB7nCwJ6VzHWQ6RHZywBPSKLzSWQfjJE
s+y6DoH13+k7ZbZEXbZct1AZmC8LsMVcfaV1N2ct1yf0JneNrfSpkZ6apjgHwZ/Tk+VGLCPx
RkO+K7nYoPRO+UbNJJmTI6lm3FNlHWVZr5bZuTkyyUhNh9i6J+fHjTw8lvPRjHB73NdCfZZu
iOzzbELPSqxEfzbtNdqBHiJ9bycBPeCcxHgAeW8vOqlQNW36+POPET4cpwx4AnvwesJ64vWM
9ZRw0HmtHvEHZQlI9NJzQ7e3RmLJtkQPTPNlZRExK5xd9APH8uORwkQyHu+ItT5betj/vjjU
3kcl9eGPFqH3NN7I9imy1fc+RPikoPRtpHkA6Cmz5hpBPUh9lzVnCsR+b7NZfK2Zqg3OFdij
66DN+/9GsHlF6a/ll23byecWBmWdX6PlGxvS2030qhJryvQqDEECfT1MmwroLZH++/V/GoPv
GRrQF6cGem2kJ0XGtN1Ay7lOAQgORi+jir2SivN+896/sr/Q//LebwYp7JhmzgLobb2xTie9
h7/SqxoLoK9Oi9Gjh7almWOK7UtcTRaE9maGdZD4P+62cvVBweWxB9RDmM+ZVyg/Dy7v3SEr
hJxlAP0yDyMJ5vQwTM4aQ0mcnP6eLMHOkkHnrpvRu+UbslhybrGvUi8DFCgqh032pkzvoPVe
owfv0jwpje6E0D5ILyi9IvZyI/yoptZKgCeCb6o7Drzn+/33dEk97CT0AHow+guM88BwUljI
Xt8fq2j6/PPPP26CzoJlx3qy4aA2+6x1qV8k0Y8j/qDTGCz1MBargBEnEkUYgqjQEtCjTxZa
fgcYPQE9Ui97TokD6UNcD1il2BSUnjuo9mtKTzBPPVOUWsODSaR+I2ZNnbMJNmAf/tVXfiYm
zNMEWTvQnz21+rHsmPoAOksw0nP5VsQaiERjSecNSi+QHmYekm5w/vjgoojQQTVWi/TuuOQN
+lCHBvTKRR8o0bNGT9XYQSOpGEBOAO0F9KjGeo6Zur5vKG+w/YTl3zqRJ9k+LhKuI+LAHknv
nDK177wr7cYT6BF24wX0LkqPHtqW5mo30IuJUyulYYYXbdBxkf7DPFeXnYjcHbErOItrMFbq
JVE+IMhy4ebNu2LqVCDSi0lTPpxewfwCuDzpN16U3gX1aJu9ZQG9qygr6fz8bWzHlD4Q6lGx
dbZTEc7f0IKOVOI9sR5c/haXW43f0mlC9+HyOYOkH8HsvR5E3MhJU9VOoIcTHuOlBJ+Hs4Yx
GREJnXFQ9c8/h6EGqnohYT35cSxevzQAkV0m0ctuKZVYSRk3mCuFCYRxOOaRaCbyzbqfPeyJ
50eOdeTj3NER2wsH/zEp0kePXf5SeStTqPQyFeFh/zFoN9GLaPP6IHkRznz0T51lqP8UUN/D
/pvHh+6bYxMxycXRQuk6pEtk2sHKcIuYH2sCPVVjP179c6qcwiRDzncZPmyUZA1K7/Lc4Hca
6mXblFBvzopGLLpQ4IZbniKrRfrQxkyFBvSK6U0HKTfCdoOOKUHpxZApzkQgtJeuS0u8gQzj
EukFoA8OUYClttT/gy31DJ2vSDgI6I3FaaJqVyrbzYNRhFIifNhdjPUC+mZPoBdTZFeGQ9vr
6ePzBm4512AN3dS0ftGw2Ny6/cRqjg3g9Kocmwrp0eqqmqYcfvp7j6TTRhB59tJ7Lsc4EqLq
vkgvqrC3wOWJ2AtKHwD1LkovnJAWJAflGVPJlqDchuA4M2hVnx+MTgPz2GzBMxZZ+Hjo/FtD
JnrTdsMxw5RiSdoLhROLVqrWh+OUWLzz48+bEkTnBdQT1vOwEmg4vb29D/t7YiKJXig3atoI
7t/TESU9BZ6bL2U0PYC+C5nCkZ6eGIC+MDbw+GF/RyFPFvzzwmMOQu9vvFFAj9FSMVjpEblZ
BphHHMJZ+n+aN8j6TX9Ry1HTxlpa+TylQDqiQ9QFzNuQHr20hW/n/+Xq6pXkRZxaZIMTOycZ
mV15xXbPDW1hAL1qkLX8+QLoQenZcA/zpTrnhBZVHBrkpFZuZB69ZPRWNZbmCBLqu4Ee2o2n
SA/f5SiGj2zXYTc/twH9wVEAvS0EwaHdYGws/JVjpuvGIwUBUQreQG+Lr6S8SjB6AL0VgWAI
OEJA/MnYLOXp4ps6a1gP0frFF5Zgc/deMWR5OX1E5xd7ZtNTOfaeHCQbxOkpssw2nUSqN/cW
ZHuUwnYScbwpvYPUY+7UjLRYOvUbovEa3w1K7wn13ETF6fXGIiOkjeNDdPcbUSJEHkeuPcBd
3x+U/wZPqSXbDQLlPBYD/RodaIN2nD+MgipL9ABwEHr45KW7vrsTmgxD/c6KGHIpRWq9pPVs
zqEBhJEIvJVIooczp7/XHAletATDTVtbxZVYb6+aQQIrJiLJOvr7AfRYS9SSW8jTRz7GVG+z
FBvgpZcF2V6RJ49MM2rzAryLhLN3xGTZyGkbla+Zmkg9yuWHWgXzNS1IRnYDPQE3tfLulGkF
lKZGyQV+SM/KDQdXSuWG2L6b0r9Fg1PKRMetAHpJ6bWTfgMJmO2hwgL6mfSAXhrpeQC49FeS
aiNQ38XoCegNJ72B5gcJ6A82qpdm5NHTw41Cuxk0Gb1Du9n3YLTKabuxaTdUgB0C0KM1dgyt
sQrZXSL8WB595eXtamluRmus3Ukvtj4vmMdPIeLMPJC2jShOAjPbxPwsRoLTugOQ5wWD5W1b
Sr3nsHBppU+p3phNU7ok+5QmCDo4vD+ltyM9dU3N6fBiQ6p/Qu55hCQ8EVVZIvea0vtBPaUl
GFRb9FiZK8hhyS5Mh0Hzrjbnk2BzAxVbenj8c8t/pBUjxyGXckNSOSR6Vui7GeepkaqoM1rf
1BZFXBmGfpfFRZ6xwnowfKL1x5A1DEJPswcRRU85N7gWkKu7u6uMLO7xJQPoeyj7vasrXpY/
ni+APs4i/SlnKTaVSo+h4DhJ0GgpSqePXcMSwfSA+q+bTRslkofL/5QaKr/XvKRGs3kbpb/8
CZSbt8n3/z4aoDhTmPML5AgS7oayp1i6PDc2Rm+j9NBu2HajtBt20v9c4WXqk1Tq1+e1RVhA
X6KeeHWgdCM0+o9UNZYlGyCziL5BrJndXwlbDkR6NTnWZO3Xh4bGBq/vk/3N/5nnTemFtBuI
9GYkvRPoRX6lzUjPQP/73/8esA6QPz96ZHSMJgRyGxSDOeG5+EeuXXm7sHDGqIKNvrG5pWqX
/fdyM2mz/CmVZMWBdbfSoPUls7ce5eQu6ikkVnOslYXgxnpDuwnU6W1NUwLpn4rospk7y2br
FCk53tqNw1JPppqnbqQXqs3N2+S5ZKQn6m/PPHPXZW9zer2qpBLOO4k3KfE+5VjSdezCDTbE
JYB8CKD7Iyg5BPT456Z3tho9NL0XRw/bpZvjZwyJHo2tCuiLeOJIoiNCSI+yqpVdb/D6SDzB
HbT1KK5G+jv3mkCPxJtEfVNTfRzlXQX+8Nwk4l9+eSweBfuOQfjpKIwn6DhB7629FJuC0qMW
C+UGzbFn8wnmgYtYBPUdjUaGDV7udGVaoWAzugNk2GDzNvGGbPTX8skk9Hc0QwSL2bpCetH3
ak4Ktyk34re8XJye7fmcrUBlXtEyRdvramxY0YdhAb26FBn2Cbox4Z+yKoW/UmGzAHpvkd4z
2Oz6Axbpfysgp8SG87gMGIMCHwD07K/EHCpbv9T5I0NA+SEA/NjoGPR5hNZTiRWtVbuq8toF
pu9q3wUHPoC9qpoW+mHlP82NjbSpuegeWDhRCDwsXVvfqXkL38uk9UZllsuvTu3G02T5AtrN
bandBCG9vWkKME8GG6ybT1nEsaDdCrFModQTpb9rTCRhUv9EeCpB53V+sZPSe7strbR6stW7
E40DBomTD9PF00HzBaTTaWAOP6Hxag62m5s3fGYX3uUMzRaHRA/lZglZN6Tc9JNrRgL9GSgv
bXDCD/Ri1jcNj+qh6HrQeuL1Sq5HNy1mzMKA2YZIMSSa9YpZI4rSD0QwahxAr0u03Y+PJRKF
X3YWEtDHLzyk2Mxrsb9eXf0Feq2+kHlmumUqSKV/vLuLY4YJ5iHJvwWjzbFIf6NNr4ERoDy9
iV3zuqA03GyJNg7x5hMoRW/n8/DDivy30eeKnxxIL7tkJaB7KjeG8UZTevbmKCc9arzw3bB4
86kiSWHlmoUF9OpCPqBdSk4IR34lhSDopGKrP9acGCuoPZnivcdM7YNKf3D7rwUKvmtn9Nup
GmsfEO4U6Y/s0rFmQHdm8kfGRuGDJ4AnMCcohx7TDCSniYIE7mIB3Fv4F/ivGTweP+DbxtOn
+XtamDZFX3Q3/l91lWzNfv2nTrlPOgatXymd7GNKz5MFYaXnybHW8hJv7sjuWId448q9uQtU
1w7LZc6bh+fynnJaWqhO2ZW+lN6Ubziu2Ib0dySdn7MNlQX2Oyi9h4JDgwYZmHnioAcYS+eM
m9WTO/4bfTmgf69YPn59i+QbabvxAXr8Qfr8DTtLsWcQMyxqsT0Aeku56ezPb0uO93SjqJqE
Ul8RQ+1VNFIB6i9IqI8lAOUA+itlyMhhkV6TdzLZ9NM5Iq5v7O5+XJiIdfQ+LMQ/0f4LIPTo
x83HPMHPL3sRen8v/eMf2UYPiZ6t83DO9zpAvma6rjhN+pNboGq2Rw99eUCL89Y30kRPnpsK
fsydMTBuSqoR07zZfMPhwjakpw3IXKm7pZQhx0npeTsS6c3mWCQVv6W8a9NpvpJMNwsJ6Lep
/ek/dERzelGNFSI9G9+txBtngCVXY1nfcQ4fIaDft71avPxqO6NnoLfbbuxAv+/BefRCtY+B
0j8YGmIFHkINpBlB1wHTAs0b8QVsVxgvYJ4A3rUaGwnoBfrzfW2btbSL3VOQwuab6Zu5JbY3
aT2upvdIoEdz7KzU6xXWeyA9lWORbOYqyDqR3miaYhMl1nyOYajXpN4xasq/T5Yo/bw5fMpJ
5yXce1F6F9RTljEicXxxnti4Z9MU47zHjHHwfD5diN8J4Qfs/uYNH0M+K6d5h+3SDSs31BfL
Er2h3ADf28Z7WzE0trvjKygwif6BxwO9smlWVmZj4xfrP975cVN9BbJraLJ3rwxIkJy+F0Df
FNfKTXf37njiWM9SLzqmrkX7O7pIuYnlY55gBf1ts1vK6bC0cunFHJLdXIplQn+tsOdQu2mi
xNlsciSVjVJ9LLaN6KaPjz7r/NID5oXF8m9IuYnl7+T7/UKMBCQpx0J6CC6ch0DqDUG6bItV
pdhCy3fpdNMLoGdKj2IspSDIs4ZOjAnpQxwS0H+jJHrfRDOJ89JIr6qxmBNutUl5iPSUa+Yt
0u8bhUh/8P9Eu+nfOXB++/Uj7RBmvKuxkGseQIEnSM8bBciTSCNJvCbswGn6n2L0QpAxGD2f
CJi2K5IP6UYzegvmcSMvoL84Wof/KaS39dU+7Gyd8jTAYDQFxyWgnaaPvLBTeg/1Zg1W+jnu
jk3B6eGvucXTR4jbY90lF44X0qeg9Bapp6qrnE1C8WbSU4k+KnuoJQ0fvOkxmcTeREVpxhLn
Pa3uOBN4NU2xg54aYZ1UH7+g23B+oH9mhJBzA0BPGo7HYm+loxR7+DibK4Vy07VkKTcDGD6S
7HjWTfGWvflw3yQ7kF7JM6nIbMO8HjFoyaaP34dEfyUJxzwoPVi/aKQSSN9ZRiZ8HinIPvqB
rlh+T//j3kgE/npSgmgqeX7sH38VQb6xB877UvofuRQbi51NFJ5st1VeV4YLaufSPtK/tZxh
g1e/9MF5RnryVl7Lz/8FP/SvPo0cg9buRHoVUCmBXjF+03PjpdKzkZ6AHk1TcOcjwVLadKxq
7M20X1FGG4YE9C8U0DenstGr/Mp9LNJDrTGA3stguW/Irxo7CmMNp7+NuIAeWfLtHkC/bx+m
ExLO59E8WHjkCeNtoruUXQSCk3rTQsNHuAoLrCeJXn/x2QFfu3BxAJWnsbEFP6lzgrwowCWB
WvfFHqrL6N16fTZetiqzhPV7FhcxfURMjg1Ub2zlWFOmd3B6MTw2h4qt7KxxxSEoTk+UHkNH
gpbw1FO22YKaKCvp/JywXNqgntpoTeONAfpWXZYo/QKPovKeUEJc311IJQX+WzbWuLBbXAHA
e0nnDZwKaIObGDHlnZrzXMbcfGaj9McRUgxmTSYaUm6KlOemE3abaBcCbYD03YVM6btoWLiY
P8hQD6k+/4OdO9+nRDOaQEiBaF1fUhgOoJ77o0i6aSqj8VS8nnXBXdnftRdAnx+PPiTBKA6X
5bW/f5+uBZ4hw9i19ExBG6V/3PsluqXiHacdIA8XZdD4Xecn5Y6W5mvud3uTeeWxBKFnD80/
isf46q3Ll0Vw8TXR+ipap2xITx4dKtdS5ZbbYv0ovQwr/kBk0lMfFh6LLg+sCeEh9caGBPRq
zE7N/VRAz/mVHx28ztVYslQGAn2ASD+Iauz1E/TWXHUBPUIQ2u0hCPhDXHp9MESFVqqzAsMB
0hLmVX2VgLqdVt79PLjxsRmdDYSLEl9yqR+A/8JogwlTMNLziQNeHPxoyj1SCKoW8s3UT6pN
1vx87bH6qFZq4Ii4dWveCfRuTs/aDU2cSsXpYbK5JYdHKZhnhu8aOwXT5c1goJeJlo8sSi/o
/KxOOrNBPYw33pTeLMyK+eFy+qDXiBKP7DM23LAy47LdkJfyrj4FoBrLBQCMmPIGeh5Cesgh
0R9GRrFSbsgeqUqxRT3wwI/3nhGm+oFY/ammio4e1Fq5Z3ZJyPURSPQ7wegJ6Em7EdGXXRRn
TKx+70AP5lQ1VUDnF0CPIST58a6HrZBuEGCJUixFDaPr9sMPL3+JmeKUVu+P9DrnBt+A0Hc7
NHkcTXWpG6LMQ1H3wK7UVLXu3h0M9EToodzIvIbVzz9B8v3PYLjUIQcOpIdyIwg9A73AeVwE
6GXK9HJDbsAC2oupguy8SSixO6TKXUhAPykZfWkqnOeoYg6kYSsl4NeyVHIMgsNgicmAZKX3
EOkfkJO+nd7e+y6gRwjCLpvthmD+ARw1cNiDd8uaKtLmJSuX4A6kBr6D78N3c2R0CJo9aD1C
EEjGF2760VH6f+2n19+2E9DTGcF0XwLypUuHhP+WFiHf1PzULPXWJ2zbiK59kfutLnctJdKv
kZV+LQ2klz6bmZknRuyNl3xDG6ag9EK/IUp/6yl9AyjHMtJvbKyeKb0wW3otSesZ529amcZO
jo4RJg5zjTZWWmZK605cgKUZgtJ7IzIuv0W/rsfiZqmPyENvUnqS6GlmLHtuLIl+YCnelkxG
INzwAuxjomCsf4B6Zml8CNP6/o5YAt5K1GI5UgyplMJdz9H1jwf2dvYUMtBDABJAv/dYx3jh
w97WpUgs/1q0i0z0AHrMOEl0YVYsjyVJh9IPfFa93a7Jo+xT4jslyvOK93cTWkg82swDSTzV
eW28gUKPrliqG/P6xSek20OikX2t2mYpE8lIopf47SrF2hyW5LxRofTchgWUF8kKfBmg6gch
JRWHBPTqWU+ldFfSBsBtabuxizWIK3YB/XaUS72c9AdJpD94/b+srv57J85T42z7LqsaS1we
IC+keEuIh3bDHBxL4DeasEaPwENP3+Cf80OIrffOr7R6qEQvlXdrLOH+GJvtxar6M3E6nEpf
aHx9tBv5TL+ptRqpYCmdLE8l3rB2w1Nkgzj9Ms4H7Kd0wLwX0mPDVJReID1NILl97yn9Q15L
MxLBJuDgPHBL+ep9sH6ORw7O2rPrbZBMlN+O0dQTyxVXsxHW8N3csEyZAvB9gZ5pFnIrBaVX
xF5I9CS4w3OjJfqirp4y5NR0KSEHjvjEqaa2wgghvRwrPoBo4zgDfVP9BzRTPEGYLaGeaH1v
T34Ck2Ob2uKPB6RED20+svQYjB48Hho9lWIpRoequHtpelVqSl/UmGfLNQAnmq7sS7fyqj4p
c9o1v3Lw9O5eHjwViPSYOsJdrkKixyoUETgm0pcxEddtrfDcsNFeKDfaRO923rByQxvy3QXY
M9LDYxmy7SYkoM/AdANKT8E2wnYDYm9AO6qxbt/NviHa1GW7uY40Yhhy3ltdtecfMOobIQiC
yaP5SVJ5ob5TbZWrsUPnh8hbif/QLgXajm/wnVwo2VKsmTuo2AX0ed4ZCFLy0TRfJqrWTKRM
5njtEN56wt/Wmrx+uKH2eZBMT1b6J2JeuC/S35ulgbOAej1T0Ig4c5Vkn+CE4BFL75RzBKW/
KYuw5LT0g3pB6XUPlQfWc8uUYxaVM7seQQk23YWmFEojppclh/pgJaHnMqyUbrwYfQ59+o46
CT3lH0iJ3myL7e5As1Q8JpUbovSd/VGIN4nOIpozK7AeSWj5ZRR/UA86T7NmOeOSsL6j4xho
fX+8ItmWBNTHeiXQk9umY29r65eowCaiMOULQk8DSxBQnAron31WfdBB5GumKvdkHPtqOMBq
2rsxj0qtAE5/QJRiy/QB/JVKLpacXphvGKoh1ECp4VBKS7kxPDdORq83RKctLYn0dMp4O2Tb
TThAv03XYv3nxRq2GyvB7KAd6KGwuKKKxdhwN9DvGxobun7wN6urv3EzegZ6nhU4NMrGSTQ9
cZ8TSfDQaUQ7FHpjH4hQesJ2EvAdC4n0Ld75lY5cMwyjgq2y3R2RIG7RIn+ezLNcmX7xGiN5
6qf+TbmJ9fjM9vnb6TmVPgDpicyrZU2aMpHeKdQD6G+lUOnF8Ck5Q4rSEFRV1kHrRVmWVHqr
h8oN9HMcj0PGG68lSbqD0pPjXllocJpw2SY5zExp9zfZdnPTR7phyGh2EnoAvZLo4ZjR5srW
eKytItKplBsgfWt/vA0uysgzgfMM9QgohummCSZ6SedpqrjOuOyJJNrarpRVtDVFu4R20/0Q
3VE9ra3kvYmVRfuPCeWGCD26YtVMWU/xpqi53UHkMe2gLncdVOiRZQgYbr5M06jSAHoeLhXL
P9ukj+rPdUY9I71hs+TkG1pvM9B7KjcG1rNyw4SeUhXOim5b7cz/tcLMzISp1B8+sUU4QD+r
nnQaNnq23VCAJUE6iL3J4Q9ud48I9xHpkVRMIv3QD3/LXnz7OngEKk3ekQfonyVfDRnkUXUV
VVb0RQ0NklgPVcbojeVKrRvoq6t3eeVXOig9gB5+TM9UMwvoRTlXkfrKtOacp/u2br3tfuhr
sKfI1nIfFZbDTi/KsT5IX5wD/yWvuZx5iq+3AbzXMBK4b6ifypwb6wv65KWnIizT+QCotyi9
p4Ijwutx1oDlxmcR2BvIDuMkK/pyISzHHWJDOK9uBbeH++aGN9DniPQDrdBL6cZy0XO3lGyL
PdMVRcJwp6jEitXd31FGHsseEW5Jq3ugh+IPmi4mE8itYdUGbVSkxYjs+ni0CR2zFfVNGDTF
vbHP4LmJ9be27u1noO+Ryg0R+l5B6D20m9aiQ+1ORZ4slPfWczRv69Px2Svbr35aiCQ1A+j9
xRueLYUgHc5f4/Xn1jQSMTWc2buVh/A2wbzGebvnRsC8apHl+0qJJx8k3uzBeluHINxez8tN
eZ9wgH5RAX1w0o3sjeXoAw30JoeHuu6uxg4ODcKZ490ytW/7X/3WVYqF8E+OmXZAOkcZwFtD
JB4cHzcMDTJ3Pz9GyG9Pu3EB/dAY5Vd6TI2FmGOPsGSgr/Jj9BalJ6iX3uDSkHxVKQ+BTdtg
255JE+s1sbcjPVnp7/JMWUu9kfn0xcT2aS08BaaTmn/PG+gd8g11zaam9PfQecUITQXZYKg3
KL1LwblN7h0KNca/Nz0mlGjoB7ZrGyXRewPbXfo983erkYrTblC89SzG8iQISj/wlOhlFL0y
Vz67gJSbawMGzuOE8KyjoqnpVLTLBHooN03175A4z9q8zEaQEk7iSlNTRX6UjJlf4mKhu4ii
K2NdrXsHjkG5QdMte26g3BzrIhO9AHq7Sn/IJdZAkp8cCZwC6H/kzhq5S1WXYrHCiI3Q+6v0
ZKJn0s6JymLFbEgvfs1ILwqplIRDMowm9KblxjDTi2KuknhwepBILx4nv0JhZkkoH8hwgF65
K4e3p+G6EbYbiDag9Ai9cQC9U6Sn7HnvaiwSLNE2++tfO4Ae1wr7YK8kZUYtTq+BHg+Ip/9g
p/8Dj41tPxKcVDyEswHBd0qRfmyM/JUeM6bs0g2no43ljUr4a/g2lLd4Sz3oWqXuTqQDe7hh
AhZ7O9LLcqwT6YuZwgsyL+AdSv2CD9DbkZ56Z1NSepGjgIADB867pXrRTWUmIxgeHCHbzFOz
rDTc+7J6S5QnnDe989BuXH1WOC/oUwG2B9DDvTnj1ujv0dGEyVIE88J0IwAfUwSVRA/PjSL0
SxBuKrTlRoZZom3qFJA7AtovGf1ShJLok/mUXMzDw0UXFQk4MfyPrgAY6JvKeroeD2BALMyV
hZ2tPy5F8mPJinFhohelWI3zCui7P6secgjyeAEFEzvWfY1bYpH5o6cRXJ9/zUnofZGeCP2n
186eFfkHYp2yBpKQzRKJapgTJUqpJNQrtd3DRG+PNuOcBKncoPpKkg8/jjhhJNQ+CMeFFw7Q
q/FSpSklenEiENVY8tMDlQ1VHvjvJdIj7MCrGjuK/MnrzS02oL9+/SB8lzQEkDIOwOFH8d8Q
6rGDDxjj9YRwHjLliKR3UvrzsN1QfuXLAr2N0VOo8aA4m/+0i7LqczNTbhjs8apLG2p3mFCv
tRuT0xdTCg6TeYvE3yORxw/pbUJ9akp/R3ryAfW3nTNlPaCec+m9xohL2UYlXS5IAd8T7CHL
36RfsIpjt+B86wg2pmYp4zZg/AIZe2ZuuoGeP3s8WUpqNuIfEHUt0ZPnRucTt0XHu0xCT79o
jcMsWZ/o/FEgfdEST6CqjzLMq5HimtYnErgAqGeg31kRjzzs/bHzy8JEJNL7rLe3kIA+pgg9
lBuL0IPSd3/Wcn/YnBjCn4L1E3k6xBaM2QjtF5LJiwLoTYXe33gju2LPviPyD8R635w8JQ31
QnXhmqxYMszA1ixlN9NbQ6jYnIMEHW7B0jK9MoGGM2QqHKDnhg2slOOl2EavbTcUY2lPMkM1
ltPOjIVcsyGvEeHXMRuWumaNdf06LDZAeQolo4RhuCR/f2QIdyeEd8TdDFKr65htQLhbpEcK
pp/txqbdjI3BSI+6rY92o/utRHz9LoQay9N5Kbf2/vRXrp3Yr0xPWmAvrfSM/TIJQRdgQeYx
kUSBO7F7X6A3kZ4o/dMA8eapHDM7R320t9xA74J6F6UXCs5tika7MXtbwDttJL/1jK4nfCcV
nyaVOKyWbu2GfDxWLy2BPm6ZmXUB/b9IQu9k9OyiBxFnc6XqlurujCO1smPAEuglpx+ItcFj
GY8Lj2X3w34kI+xsS5BrBm7Kx7DWP0QXlUytTySuUIw9Wqrqabo4hhT29F+LFhLQY5oggJ50
HlZuRFesWI3QapwYj5P+SxB5fGy+L7fcvEdPJys+INt/AlOhXEDvrdILb2X+2aicY86fxH9t
zhhUrVNavpHjp0DLXV2xFtDzCFlTome3jgpO4Laps+oypCCUj384QK9t9OkoN0zokUlMI0Uw
FtxWjb2+/QENibUtAD26q1waPa4JEDpvAT24/D6EG5CfBrJNezukG4L4gwf/IAOLQebl+gOk
GwSfoRqbQqQ/koexsZ7TBJ0iPWZM+QO94bshpAfQNzaLIYMw1acbxBfK4bCJD3rDQexB5MoF
s18GgMNKr5C++N4tQeZnnxLK05Loftu/HGvvkqXAhAV/oJexaHNyzOwd2SobJNVzLr0jBeeO
JdsIpJcajrblOHk9HJW3JM4jAk2Qe7EA4naTvei01bfNQMah2bRuoGfLjRgVa2P0UG446AZd
TsJzcxhtsJ2JBFJu+pWH3sL7ot7xD5qaotF+Lsh2d1GqJWYIchraYyTVtA48RugZhyOgEkv0
vyway29rA+BDn+mPYFIsgP5xF8XbENDDgwPlBo1aqNV2n2ls/8il1ZBYU5KpSd5xuO6wLhVr
2i8lK2gI95UP0N/lwei9xZsDPHEEIP6vzYeO9htQD6S3lWQpyYBiayTQGyze9i3uI3FdaPmw
29uR/h3NjkP5EIYD9OptTMd0Q4xeVGMRS4lMMxvQoxrrAvrrPiL9vsExOCgloQfKQ38niw2V
YcXKe+CdSQ+cZ5Ee4s7G2W4I6H1tN1aGgmT0jRD01U5rCCnWKJTj5+UeNLdu2kbqaqbhss9V
Vnqm9MXKTTm3rGBeIz2dEZ74U3qD0/uPCc/JIZ89xaLxzEEKsMcpwYvU22z1XpReuDONHBzS
cZzmSxPsaRTVHHvuJc7LX7Ilx87Vic8bwv0tsHvS9RecjL6Y9icUek3olUjPyg21SzHaQqIH
0Bf1J6Nt0a5eN9Cf6e7AJJGKJFP6otZI/AqC6MtAyZGdQLYaBOG0DsjMszgp9Oi5iuVfgZCP
ibKRyLV4WTJ+7OHDDhr1l0xoQt9/prn9IxeNB8bX9aWXJh9wuJlJesONsbIkwXxbPUU2nEWK
vd104yfeqFJsm+0PfWhSemqdUhlniCdDag2fTip4iIifciMJvS0QhzMx6fJBKj96hMfLfaZ8
7h0O0GfkrjSA/jqQXthv5GKR3sHoaUCsr0j/QETRA+eHhqgtCg4bxM+MjmK0Nxi9LcDSod0M
IZHGCfROkR7haEi7Sacai46pFn9/pV2kJ0bfCOn/gYT6mrqMO0NCOTY25UG/L3GoOHT5DvWd
rPS5L3Jka9TsvWLbxHDJ6e8S9w9aOqAe+D3vSenlAEL9S6XypIB64aU3886ecEctDaOysN2O
+y5mT5rNLBnoH7k0fDbhW6SeZRoj2R76PDg+VCIn0DMthIfe6IgVzF5FFENjZ3MlVPvjNFiq
Im7lFRsKDtqm0CBbn+wApe8eiMfqYaiJYig4XQ1AuCer/LNWkYNTKEqxiXgM/kpoN/mYJJWo
qICE019Iw/+STOi7TrcMuqWaleGpypGFlz/QfjAkm5r75xBeT0CP6YY0mTV5NoYISkqft4z0
3kjPpVgy0aj8A/HMfmEHeiTfED8X5puLfNmgpkX5Ar1utiK3PQ8bofBjmZTGEv/FXyvUfPnd
4fEIoQC91S+VnnTDs0cgzwOf8S/+z0D6626gh73mgUfcDfXGDg0x0MNUT9o8WeaB8nDdAPdd
AZbOTHoy5nBTlbEcRnpIQVSN9bTdmCI9hHfqmErN6Fmk31VN86goLG27ZDvDYQ0UC+UYeukH
/a6v0so15sN9uKFuJLeYpBlhs5HJxdbEcIH0QQ5Le54lDx/0SKMXNdhZa4I4qfQC9YOhnim9
kYzwhOX5BSHnKEhf8M8/Y2iX0WfQb5yLtBvrNqb+2Fi30uIG4P6Nbx3F2Nv/JJpilduG/tW1
WCHRU74wSfSA/jO9UNWjHsINj5Ht7idzfGwJkN4Zw1TwK4lxKDc0mIortALqKQcHI8ObqE6L
IBsI+U3JKM2iaqvI7+jpiJWVRZPjp6vvO1ug6D0uBY9fp3vSccTlTlpXCUebMXfwWuxsFAhM
QE+UnrSbt47BYGlHend7LLpihXlS5x/wX9p2zIX0ynwjouVpAOwHlGTwqRlcaVdxhHJzVrow
SbkxxRtcGuixset2GwV9EEMB+u8yY/QQb4TthgqxxMZNCk9J9XZKj2osEom9fDcAeiqyUv+r
clIipGYfTh10EsiDezJgnuADEvNTiPTnqRPKx3Zjr8Yy0Psb6U1Kz0DfSEAPqFefiNJw3LQv
jcmhPcCNkQYH2JNoD3FGkHmfOASo974OSxvSk0p/15wmy1guarC3LJjHbXdxi7whCOqJ0s+I
FGPKtpSyjaXaM9YHRBrzr9luY0afaWwnJNc/kBz/iDaWN7G0MwNCf8Nhr7wtCT2DuxVeie+O
F6FLFVnBSChWEj2gvKytfrzTabmR9Vjw+Lb6Jqj0zwb6yzAQNknjRsRQcNUwS1APY02yHr+k
qYPjV+oRbFY2np+shwknEum82ni/1K3UrNTgom3PRg3dmTOGHwznFeESg+aU5EfLQLUl0JeB
0qeF9NQVy21Mjj7cr3ggiblIvdFjAfnPkEgfAPQOz40g9Eq8YeuN7pgKxWUdCtDfVEDfngGj
RzWW9XkH0HtoN34i/fbBvLHBIeqQFTg/BlpP5Vc+ewwSw38A0DeWWY09SNXY6rzzwU56uO3J
doMQHPcyW6ZEBoKvkd6h0TPQy0niQ2q2wvSbBvWrqzf6Ku2aPaj91GTtc1fnlK7IPg10WJpQ
z5TejvSiBnvTkYNDlP6u5P6eSC+1ek3pCemFbOOozgLKMaVk1jP3TN6IywAbdbew3QxQ4PB6
Anp2Y/Iiow4CmGdsuWlP9tAH7yOi8cpFLxk9GDqbKzvYc4OZI4D+7gEMliqLuyw3Cuif9SQh
3iTgpoxXwERfhmkjSrkxoP7HTug/9dEI1WWvVWDDKxVRzDH5ZaMniyfvZO3axlHWmQmrLaPm
YOPjpS92P9x/4HLk05ih3VDcJg2EOmaPQXCHm4mu2ET953/p4DN//vlXETvQU2g9yTzQbuT5
BJQegQi+2o3RLSXngSukl678i18p1JwPg02FAvRP1FNOmUYvTgRiGizGCVIYvT2b2FukH8J8
WA8nPfqiAO1ilDf88jDKE4MX5dmDo2MQ6R94A72oxu5yV2OdIj3SbmC72eWF8w5/JbfG+vkr
bbYb6P6a0dP5aVBVZd9AqIdBbk/llJMElhZUlu/w5vTBDksD6YnSz5mDw6XVxp1gTDRfizze
UE9Yb1B6MabkrtOEI4m+5bB0QT677u96ei/hyFHajajZkgvzhpZzqIKLKVs37QGZ7NC7Khul
TEavI4oJq4Vyc3ygd7wt2YPsMu915syzSEVFUxKnhhiIOsQZCjCAO1L3y7KAM9CLraKxni8p
tD4KtedrbxYPiG+YKLm1kRj2JzMZ9Wg1qsNfYPUC6ZnSk0iPYuyVK8JKD9/6Mad84xBvoNxE
d/79r7yf4y92vvczE+zZUI+OJykRoRZw8R2SiHzEG+m5kYE4UrmxxBucMDTQh5J7FQrQ6wSE
g2kyep49QoNjSbWxU3qKKnZqN1yNdSE9hPn2duqHojU4yBYby1R/fQjzBEnG8WX0Q+mI9AD6
lvZdnozeJtKP7WrBeFl/oFeTSziy3mT01CqrpPqV6b6N/GC8Po9VPFHg8t8B7ZnbGzo9hHry
5PgE3hhFWqrJkiRDY2UFhkurzZyHbu8YM+sL9ZrSS9nGOXOQcR+dVdQl671EIPIj9UubTg9F
fkFaLsHeuVoLYq+BnseP35y5dcuM0+kjnG/vIBh3MnoxRZA9N8JcebioJ5JsQ9qkt3IDlR45
lolofVt+JJ4gE/0497Uayo1Q6pd64xXRjp7epccnm721eAHxG6PGW4fw78xZBzXtxwd+xCKg
/+KL3ft73opDu0leaaMqacUHSUoqiEG+wWTxAzal3kT6A5FTH/9F4GfkH9//cNyKQ6AmWaL0
EOmFRMTajQ/Ss8GGE3HgraTLC720mz7cDIRQgL5EMvqaNHFezR4hgyWTe1OUv+7KKpYivdNJ
D/iHk5IaXwdxFxPkuT47OJRHna+eQE+M/uADtEyRuhNUjRW2m3SqsTDSpwH0omOqigbMSulG
FBfeeKhfXb054qb2MOJN1u4xsL44lcNSoj0BvKT0BPV3SPVA0dUmzmvMt1F6v6osUo3B46HS
K9nGPXSQgJ5OAqYPx0R8lGqF4mNbymIpu6lu36a8M4ZzYP9ddTLg7Mub5KO3Tg9PqMhREx3v
HDhjmzjCEn03TQ+hvtbOJTjZYa7sjkRhudGDpty0/syZAbLIYypJG2WcCRM9ThK2VYSRgZdO
t3sZaujJTDfUlTzaeIKxrcScXjbYuJtQXiN97/7LkULy3aBdqgIwn7xYFqVMGswWjzhIvQb6
/orfOvUa76f9Fx+fkgH1l3/GwfUS6JXvxke8YeUGgQcyEMcAepVyXHZRXciG4sQIBeh11M2f
pRmBIHqmBgcHwewJ6M0ks+1Q2R0Gy+sQ36kzitQbta4/oOAyWOZhnEHx1ZlsBiMOhB10vgZQ
eq7GOoDeod1I241nCILddtNuGOlHT7hbZK3uWHLoNMKLaUyjykK9/JTllDfYsnGEJWe6obL8
uWydogCcQIellm8Yv4nb34PmQTVYv/gb95hZb1YvQiyF20aWZV2jxCnjnlNxXJyeu2hn+LLA
i++TCs8gTgVbge/4TvvtIefcANAvmIadCdo5jR/WJ8Y7i4jSC88NcXtI9AM8RVAqNyTRo/kV
zVJqoKCHfANK34smKIA8TJP1bKKHcqNLsWfOHG6svv+Rl5+GIL60oa7v0TqyhdM4K5jZeDUf
NbYqlFeUfvf+yx2F8N2UJWmRSz1KSJ/IJ/2GSL3hviGk70p8+IuMnulffl4BHw4myZJ2Q74b
ct2wdsMSkYd4owPNVCCOxeiFxxJXBslQw25CAfpayejTjboh2w2L9Az0MOBYc2PxEzVB2Xtj
EX3mcNKjW5Z6o6g1CpNjnWxeivSjKUR66o1N4aQPBHoD6UHTTSP9bxtHnVBvDZ7FSNlm2Csd
QJ+XpztLpt+QXASfz/gPixNOQ46G+z0vUjssFaknSn8bfF6K8wGzSJyU3ofVPyVpnjPM7mqc
d80SR4YljaOyuS7ZccM4f/sJzDve2g7uyNFoAHzVNsuNtFLPIbPOTTRMWYS+mMMPYHH8KhEZ
MKeCf0ZBNzRF0PDcnEGzVBuUGz/hhufHnumGvIN5IzsxQVCY6IVy8xkhvIcpnj/2DPF308Dr
dW2ybY+Zdn20uXtg4PHjxxbUs0iPaiyAPsEZNNFoWeKddwjpE4iYYfkGQ2A11O+Pn/pYTgHP
6Pls+8WHUUo1IIQWBksCejkV0I30ejgJXVlQ/AHNFVSLQ28g0ivXWShTY0MBeqYW5JRNl9Fj
QjiHINA0WJozZXPSw2BpAj+dCQb32UV60HnweZE+zFzfYx2ESN9+xD4i3G67OU+F1hRO+jFk
KfgMmTJTEFBtxYwp7a/8/ucuSm8w+nYCeiejJ36vob60NpxpBBkd269049/tANp7OPXA7if6
/JPNbJOnGL9FSOWMlzhvVWCxgSsax4PVE6VnuHZOHTTlemyAJion1jPO3wSXh07vPWocXB/n
AW7DUuXcG9/OGNLNLID+luXBFNbKxvGvEDCcuFRkEvrDx88R0AvPTS8SisHnYZ5MVsSNeSMe
2g1PmwLQfwyFHspNf+eZxqr7R/0Qnq606vpuh3iYQLExSjfD1d1LAHleGulZosecE8wOSUSj
QPf8BMzrZxMS6km+kUZLeOp7vvrcSCPO+In/7fsfRhnoPxBZCwB68tK7Ob2Vc6OijN/CTXaZ
/uw7GujrMn4madwhZKBPV6QXQD9KQM/fmhTePVAQ5P8I6/lCukF2Gc0TIUMlNcGqFAQH2JN2
swtjpvxFegRYQqQPbpmCSbPFL+3Grt3AX0kbEsKfXv0Hf+0GoWYE9M0uRm+D+uHKNycYwfew
3bZWO+n0X0oxp6Cu9nkqBYcovYJ5VZT1DsAhP4tHd5UT60mXQTHVBfM2uZ4clnY/DvF0mj9+
iwDcnnxmiji4VpjjX5Mthxceyvh2/vatGzMqQO3JkxIOP+jtGG9rOnUq2UMOSrk+Q0TxwBKN
i5VtsccPn+ntTLRFyzoCgR6UvuhZpG3nxx/vvHS62Z/DM8KXv3jJoJpUYLWtzww9HW4//oVC
eQelZ0J/DUCfAMrHYteu4XtAPfSbBPFpKd8ciP7W3hWV6u/7SfZNqAFQ2g3ybuT8VzfSu5Ub
ykQwkB5tWu+UKZEylPjKUIBepxT/WbqU3sboWaS3oB5A78wqhkiPTHqJ9Af3sUceHbCDFEns
D/T7aNZIgEg/lEezv+U0QY339ubYI1SNrdqVRm9sFQj9LmG7+fnqr1xNsgajF0CPPiyvZUWD
NLwpcWfBH7ltOeWVbk8OiwbQ7mtLdLalC/eXZRTxPCv1ru4pA9lJpfcq1NoHkgi3zV2v6bK6
kUqUY53xZ7dJ8BEYTd96azeo1c6TsmMZ8cHupZ5P1xJ2oL/DsY2NME3GviKPzED3cUOix9RX
ctFrc+WZro4ysPRA5eb48cONLRBDp30pPLoc0MG8vAlXmz+M2FD+/md7eVlQb1F6SegB9BS0
82m8kJQRijUA1L9DRVmQ+reOHeuBZvO36wN3417bfvF5G8UXAOoB85xCSf2xuGqwtcViiCBH
pRGhF8oNhpPYKT1++/oBvYrnmU67Fitnj8iYG45CsPJu7Bn1rO2IaiwzevTJEpFvH6WYGzhv
8ojre2o3BPTISPCl9GiZAqV35Jo5qrFku6Fke08nvU2kh5Eepw0G+v9xdfWqS6S3mmN37fKR
bgTwW1A/9Ya6LT0+j9/vqJ2cckcgEtwPTxdU1pW7+P2yTLWZvacCcAKgHqcE75lUFtQzKSe8
9pk5qLGekNxO6fkMAds903Og9y1P9yVpN6Zw8+QJbPcS6GmKFYAeAWxK1uG62HYi753Rpg9P
JTsGoNDIBc8NSfQAerTFcrdUN02K7YCHHok3rnX4UEvV/e3+Eg2JslOTE333Nq7xKRBxv7dN
HB7O+6x172MB9BbSW0APQk8ZCIzz0GkiMNqgDYpIPYR6Yb8R3VMwSo5/+H5GVVj70/zLz9to
upQKpAfKM6X3QHrVFkt/XDgwQejtlB72HQX0ky99/vF4gFAYvQb69Bk9VWNhuwG8U/sUpQ1b
9VcAvYdIz3E3JOxTe9QYGqWI4lPSwREfkf769aFd7aOjvikI1wH0CDNOAfRBIQgm0O8iI70A
+l04mN4LEOkxtgrplT6MHspO3nWNaKW1fwzjKHhdH/NWSV2Dp5bDRcEpEPy+XOm6kY7KmZsa
5oNY/R0fSq8zcJ4KDzwp7U/8xstKSUc4LI3FOK+x31e7kRUALdywzCPIv3gEAP0tBfQ8V6rm
EOquxwcwHbDpVEWkp1t2TiGm0qncdKJ7tYxSbijbTK7Dh2CEPxiI79ip8LeWzL8EOmZ6qN2s
NefKD7d/trdVgrw3pf8C7VJCuQHQI8sM7bCXcYMg9Qz1VJNlUs812QPv7fzrTJ8TtofLMg6e
LoeCqyFTPkiv8ohZoRdA7+D0nKagovRfH6CflMXYtBm9tt0QvFNqsa38ivAah8GS9Xwi7pBt
KNcGSQfSaYOUSl/t5uAgZkiN+Yv0f0CApWucoJe/EtXYoRTNsZQyr4z0J3Bg/G8BIv0uAH0j
TgoB67wKRlgZrpxZx3H5k77LzB4/di/cOQWTdeVCn7+pHJYpST229E67FFDP2guY+FMC3ID5
soz12MacO6j4vIJ+1uK9Fhs3WciXC9AvyD+fZR5Bs59VI6yYW7WznfJ4KxzyTacSsU4l00Oi
HxDKTSfPHEGzFMzxCRJuwPmB7+2DwfjOe7Gydk9IfknfozOnzjTXDlcdHjBR3ovSoxQrCT3D
eaTnQNf+A/2XI5rUs/1Gk3og/e6HXZGvPv5PGXxCfvX+h/kUVqxSDVDsxSPSkEA1Mpxou6He
CBM9lBs5WkoQeptKbwJ9QwbPJe1NQ2H0GuhRi01XvZEhCBbQG9oNxoE4cs3AzpnBU0olyfJa
rYFIP8YTTNzr+j7SbvICRfpqmjIV2DMFdw+C5r3TbgzfDRKS9YwpboCo9qX0CDUDow8GeiPu
bGWl4M1LwUnjeP6huLyuwMuYI1gHE/yJvtzZu7Z5sn5SfRClz7kn6PxdTJel7+xDZt2lWTLW
WAZ7J87fgSAjqrVOsOctzQAFnF7IiPOElPtbNx6hGHtLAr2oxH7GC5XW8egphMlHBkim5ymC
SrkR02IPd3eMf321meUZDyeTpGlirxWgzrpnMym8eqsdo+RRfbVxead2I403X3ypCT0E+six
fphr9u/H4CiL1BPUQ0GJy/Ab3mD/gcSH7/tkH9iPvV/8NkmiD+G8IvQ0H5wmfbOKI3R6KdCw
UG94bmzKjSnT05ngHTVi6vUBeiXdlKZvuhHV2CFgNCffOEV6jJSyLcQdjKJGCzqPPlizC/Yg
+D2fArwMlqTN5B3xF+kpwLI6bzAQ6JF242+7sbQbYaQXo0f+FzpU3vUX6QnoUzB6h1g/XLcB
Gd5pgOdruMmN3PK6hin/+iGwa7oAkF/et6bD6r2sN0a0mfPXdBKYAbcmJk9TpOacbhwH1pM5
RzgwVcylbbA4STSmsqPxnoDeXqeF7YbIP34xexNAf/PGjMhPuMPEt1n1R3V3RJBHdqoNY0OI
srNEj/yDS+dOQ5xJje5K9ip5sgllVu9D7E/ltnr70arjXxiCjfmtrseKzliT0GMYOdSZ3b2c
cyZmhbB8A6QXNVkVfkNAj9/H2lxpZvZnh2wzHVhsEHrA/DU56luNkRVTBWVF1qbcCKovGb2W
6RnoXz/pRgM96Hy6jB4ivTTSE9LbU+jRIOUS6TE3ENYb/Ecxxta6DiXHX7uBSN8e4KR/MFaF
nisxU9ZaGdhunEAPe87YWDUfLX3+2g3GE4LRi5zioLUr76BVfizo20Sh9PUD/G3ze2orG0o9
y7WKsSrIL3nhgfQUhuOZkHCPQnNgxL8nAuuhr9y0U3q+2Yb12GZW3sDXAjac5zwcxy3M71mj
t4s6qMHiBjB5dMXeeITJhTN8IrjDNrftYtwIoX13NyVPnkLW/JlDjeAl9w+WHk3B3Zm/D09B
oOkrDiUnN/1jaHbCjLWr+agFXVE+MO803oDQS2/l2ViMumD3P+z9onf3bsQME6mnmiwhvSD1
VvgNnQgKYb3PP3vx1Mfe1vq/e/9U3DZQkAk96zHAeVh7RGaNRPp3TE5vV25UKdam3rBG//oV
Y9djr5RAT8xdiPQGtAPonSI9kmsg2QwhuswRd4ATQN7gdk/jDY0Pr0JHlL/tZhTDv9uPBKYg
DKEVCqazVLYb7pgiH+bY2Lt8iP/bAKCvQqpZKumGzwC78s5bXHW4cqODotL/LL42W363PDIx
OeWv6Chdh1l+7UjJosZ8n64qpvMzs6KfCohOcHw7xTgq2uYJIz3j/BNH/BlufOROviR9xvLm
CJqPLYHsIPS3wOYXNNA/J/2l5vBVqbkjTwNjkgvap9C9GqzMyFMelTEmynfc2gLUAYKNOZag
5v5pxCR/oUw2XnBvWixB6JFcCcRG3gEYO5VbdwPoAfWK1APMqXlKKPVW+A0Rej4LQEW/ljhl
jganQ/0vP8TY2C57IL1W6KWRRnjlWadnk6XF6dWWynMj5Bzxn5VK/zraK63O2AxEerbdUPyw
AHpzdOz2fezHMdb2oSGKL4Nqw94bYwUZLAH0EOkDoorJPJlCpA8cMmWK9HDH4/MGeJeKerMf
0o9hhqGVR5+C06OtartFU6dGtsBn87UA/VvPyysbplMBPuFlTSlpO5MQd0oWdzip/r1HjPNG
tvFT4PGCT8Kl5vXksCTlhlyRMwLyDbAn+ccF9GJiFUJ0HH4diPJkpwern5VAf28HU8GjyJ0Z
ThPZmb1DfseL3JPz0tNaN+wAmLc5bFbQ+gqw7t+/20+2cXnpidAzYicEoYdCTzDPUE+s/RgG
ANpIvYypx28iPFqKxHtKSXDI9Unn3BGSgqQ1ngk9iTRiZLgb6T2UGwvohXgjoi3VGe716YxV
WTfD6Ss3QHdIMINDlHYjDJYGo6cYHBvQwy8PuR0zAu3BZtwmS9qNn8HyIAUl+Gg3lGApp0wF
ifTnR8eqWnxDEAztBl4a8kweGfufxQfh176UHn1aaQM999E263BLmHBub9jn7E14oO/u7Cmv
mywIEvGNWiTj4fRUweRk3URt354dNDrcacdh96Qf0ksNh7d5emfBwHkT7XEeMFISBLIT9yeL
vQ3oyXazvLi8o6S8trausqGgYLo0oBpheyGiIg3uDs9p+fM7GzXfacOOmR9K7OMkjzZfys+P
xzHr9eGPvrqNA+mFQh+HFM+EHgr9Q0Ho6YtqsqTUXwOgS0u9km+O6TMA3++tTw7YKf2vejyA
XkwGVCFlnyDijJGevTe0NKd3KjfULOVAehFt+VoDfQZQr6qxTOkpgNJ00psiPdAcrbAAesHn
7Yx++wOIOn4pCNePQIMf+4N/Jj1CEKrQVBUk0geGIDiAHnrMaKP8LPxVANBTMXbXLoqmT6XS
M9CfPt04aF2Tl05k0xHWgTffPSkpr6sEVKalbmhdf3gYjH+qoKABpL8S8F8+sqN47qn3gFmr
lYqFecJ5ODLdwTikyDgo/TwaYp/3lfSVT9RVVk42NBRMTU+XloKxu9E71S1UipisrB3ZMbdl
Z87fnTDN8is12xs74vGYAOuu3Y9bnaZKO/Jr8eaL3VKhzwehZ8vN7iWF88TpHTXZMinfFEao
eZYUehFw+dYn/adsB9T7XoS+UPS6CkKPoLTLP1NIL6FeIb0eOaK6Ygnm7UgPQp+fX6au1F+f
UDMrpjjtWqyKNRu9DpXeJdLT9CnDbglC374rD0Av5kzZF8j+KNpfvR2WGC6CUHrfqGLRMjV6
BM5933IsDZnynT1iaTdj3DGF0SM/l8fM37qnkMgYBMo/I6DnISQppJu8XQT0J7G5njmID/pU
+ZZjaOuA3ld1F8Xyg0u3wXhaM4wzwPT09NQUTgK0GmhNYlVi1eGMUFtbjoV/JibqJuoA31j4
NW+HhbtMFUwBzoHnoOnrAHTrCdJliFCf+hbnt3qH3R9LbKr8yvDoIcTyFMZjiKmJQ7n58ou9
6QJ9Lyn0mtBDoadKrP7aTUK9IPVvk1APPBZ9stc+RR4OLJIJKDfcSnV5/7jtWPzQNTJWDpfV
hP7Y5Z95Ij3iDjibUsYfmHNJDJmelBtcHbx+McUj8pirYctNur4b6n9CUvFBJdKb2s3gPku7
QYgZtHSKL6MMHBfUH0QKAp0CvK30qMYiI8G3HEsoXgVffgDQIw+Z0m68h0wZQE8dUxgmOPpX
6pg57eekp/myjS0A+pSLNlFAbwtHWKnJunA24jzx3XwxZBFSRaYyE0VS0epwfy+RvQ7I/vze
zU1KJtiA/b1tsc42NxIOm+N7f3x4oIcNMjH4I3sOEKFPD+m/eNglFXrRFEvq/hcmpYf7BqT+
E+G+4UBL7pPlRT+T6fJTLuHut42aGsfdbIuS6O2EHjgPrD/2iZgYTtKNirKE8dLoltJtVBrn
aSLhp3DhW0D/+gwe4RnFtNJHeQyZgkhPQA9EZ5HebJJCrpnlpKc0ekowG8J/npNjcRog9d7T
Sk9DqAJE+vM0fIQmivszeh4yhSqrd9qNpd2gD6oZzD9Pf+ze83XSM9AjAS0lpccmzOhPn0bP
Fv1w3pj7UNPwfAM+e9mHsPbADzfvPe+rnaicLCgozUzhCRfXuXQwBc5OyL545zVCdvPoum0v
va4g3qCzt/fHH3luCBH6GBT6y1/2gtCnB/RE6LmmqppiQegpn97g9MJ9I6yU7L4ROfUJhn2g
Poa+iskkHxvP9O/IZ28HenFZIFtdAd6AeV44ATh1etFKJfLM3sasWJ12pr30TOixiTpoQkm0
CqUzdlk95UwYPVltyF6jfDfIPbByza4f1NoNBZdh7jdlE6M71s3o0S07iuGwPt2xpN34xN2I
cYKw3WCGeADQs+0GAcQpgb4KQL+r/aQ+Yv69r0hPEQjE6DOSbgjn6RLACsJBb2TlchaoQ9sD
38zefvG8ZKS8Frr5JMB/ilTzlxNZUpwQIAhBDwKkQ4fhekDJjmKMjn39rVY3a81keZy4Bhv7
C4/1XO76cn9X1+WOt6DQA+cBul0PfyScTwfpidCrOLNritA7Kb0g9dJSj5osT58S1dOkAHrG
+f1fGUfRxzSGyjEXnEuxcgAstB69GOnxG6siS1cLalisbaKsDkIQhP6dcXUwLIZxBIcC9LPq
KR88mrZw82fUG0vTBGmOoMtgCaCXKQjkwSRfJcdWkhvTJdIfRDo9xkx5azeDNFY2QKSHp6aa
onP8kV7YbnyBXlN6eGnISP+efte2kdfSseTM2BbEV8o8/VQavZRuMKdEID3+3fWR0RdUWhnK
WxrGsfcTecxt392agxGmDycA0t5JfZfau1DrhfDO0juqqajlYllqvtLyhZRfNwExvxwCTO69
+ZlX1pca7hvzXZ9dlF85Wn3iWjyOPGFEkPVf7jkGPn+NCX1hB9QXVm7SAHqaLNVDhF5Ybo7B
rsOE3kHpNdJbpL4seTGJybKYIZ7QQB8x9sEpnixrIL3U+QXQU/H2MuYKWpz+UxPpYcshOm+R
fyO/WDrpZRKOBvq5MPZ/KKjwjQL6++lTep1rdnAf90w5nfRSpEc4ArXDQr/nTGIIOi6ovw5P
DlR2b0qPuBv0vvqK9DhHcDU2SLth241v2o0F9CTdVLX/K+tdc0+OldVYYvScR5+K0mvpBsVY
gnj+AtLvMrKMiddnNZwwPivZx3zpPfDHkkr7DODh+6cj4+NgvcB1gvq3IrDA0KgQgDWm1JK3
UgB9SuONIPQoxVLPEwg9eqUEzttV+t1Uk+XEA22pB8bTFPGKJDJqcIYgQr9//19brzXuAHoS
aITYwulob711+Wc0QdaB9CD11DlFucVYwm1pnycrtRvhyjl79ucKNUNpbAgF6LdpoM9ApKe5
sRSCoLQbZJCZmfT7BKaD8yOQmOu0AHqB+E7fDdVqB5Fi7C3SY5SCf9zNPowbrG4fC6zGUtoN
xPfRFNrNWBWk96oW47Mx4sfod7WcThvoidGf5FniktMTpac1Zo5pHm4oef2v718aVrIPsJX2
wHcAeZuZqOZg80CkEFw+BlwnqIfLBj8RymM4FH46drmrVxL6FECPYHrkE1MNVxF6ttzIZVPp
gfTKaEmWemjzyYorPAsweTHKjJ5xfafedX/JPxuUXhN6mVH2CXDeAHqy00tOT7NIOOXM3ipr
k+nlONmz7/xaoWYoxfRQgH5VvZ9T6TN6VGNphCDsNTKUHkPBrSQzRCKQWkMtVUNcaCX5Hv4a
PX7E1hw7iGAzn/Ej15FyUGUX6a+rybEk0nNvLLpnAyi9qMb6DJkC+h8RC1NMMEzwXeOj9u/c
QC+mj2QE9FCETp+mSwqh2wjxRqyDJtbXNIz8RK/9txJ6ZZ9LWnvgT30OJl9ztOqzzs5+RK0R
1EOnYaTH3D9GeYx7hYoSP9b/kLyVaVF61SwVIy88bJma0HtxeiPmLPEOAX3blfr6K6D0Z+Gu
FEBvSa6fS6DX4s0nKOZyPpok9Az0FtJLwg/BhrIsMXuKwV6pPDblhqOKpUSfeFd5FdPao5lu
FA7QK814KgN3JYv0oPRE3YVIb2+SoukjuA3dTNQmxXOmoNYL3419XUeEJZ8CPBalIFQFGCwf
YLAIVPxAkX6M/JVVfoxeAz1qts3Vtgp6iw+l39XSeDot6YbdlS3NJw8JoNdQr5C+Pc+O9QXl
rzifKtPDMbv9T28PfDvi0ORXhvMaEag5MND7sMuAeiA0mdkTojoaTcQI6DWhTyXefAGFXqQf
sBceZV3F590qPZN6ct/gDsgsANDXY4HSlyXe/pQSL4m/6xSErxxAbxF6qdAzznsjPeE8hsli
bDiA3qHciAxjEZBAZw0VBTkcyiEQDtArHW5a1GLTddJThRVAT24bFulN7QaGHCg24PvWtKnt
oPRDxO6dUA80R+68j3YDJ327j5MelH4f2eQxsCqwGku2G+SLBWs3YPQtjSf+rfmulfuE0gPo
GxtxHUHsPmUxFkDvx+iB9+15uwZtvH5q4m4oB072QbN7IPUemCl3gfxgc1E3r2etA48B9V09
UFyUgENcvixJqwxAH7n88LHF6ANV+sc0KvYtyD4Gof9RQ71LpmekF+6bs9GLEG4A9G1XKqR2
Q0ivUxC2faKAXlD6v0ElgBQiQegpdNgN9GomSVkZTQ2/cuWDD6DU59s8NyqqntKTBdD/RjL6
0tS7dR1bhAP0KkJ/OhOYh3YD6QY+SsJ3ovTIKjYNltBs9gHmLdOl1G7clH47XJJiApV7Ie6G
nPTmQEEl3RyEdLNvCHwdAweDqrFHhO3Ge8iUJd00/vwf/tH5jvwvI1cx5MpYUroRQJ8a6SWj
l9KNi9ELZp+3a9TE+pXSyZJQZL91HG7Zu7w5e+BebYMZRAkYGx5qOV5U1C2B3oL6/mMowbJU
DzoPkOfCKPTySM9+4aJPLd48VukHCeg/IPQHvvyC4ul9VXol1MML+c7Figpi9NBuLuL0wuNk
ge0fynfqFxrnhUzPyfYy6JLTDyTO2ym9TKwso5MIFig9WTftI8MJ60XmJYfmKNAsCOUQCQfo
9VVIZoyenDZAet0ca4j0SDkDfbdkG6HdYJ4Uj451xyD4azdD7aC90P+NpZEelP48gB6Y6wB6
20DBFLab80fOH6l6t+//5vN+bfv3Pz9tpSFYQI+gtHQZPYqxuKKw/JVapFcSDqH9UTOLvaZg
IhTTVijHZPZBX/c98Mc9dbbwGgL5+81ningJPm9j9f09EuoJ6AHzV0gvB+ZCu1kyOL1/uBmV
YqlZCoQeKTdUUN1tA3ovSs8lWaL0Qru5wiI9+W7IF39ApyB8aAd6EHrZFassNzxwyi7e0Pgp
EWV58QMG+isE9G97Ab1WbnR4ZSgjY1fDAXoVdlOTgW7DvbG0BpFfQD9gIKwRcENALwaAW1ln
3Dvl1TPFGQne2g3JOhDpfUeEn6dqLJ0J/J30KWw3eSff+99SfFK/++2vVWoxofuu6sbTjRLo
g8QbIv2s0Z+uRh+t3WBpYLz6Ns/0168Qsd/quSevO8Bln//q6q3ySbuDEiA/qkDehfQk4CyR
Vg+oRztsfrQMMN8GFYUoPbSbLnhnLKj3RXoqxYqR4EToIbMzoTcovb0/lkR65vTUYZUvtBug
MQE9Wel58tSBvxPvZlTYLZXzBiGVImtSxZmRt9KF9CjIcpQlAz3J/9BuSLoxSrHiW6HcEKHP
Vw6W2lCOonCA/rnZGpvBmCkKQSCsF9qNTaQH0KORyT5/BCmW3r6b7STS+2g3sMpX+Yn01BuL
aizpMgFAj2mFfiEIo9Br0vQ1/nXfu+igEiyegR7plSkoPaUkIBinEQkIVRSNYxVkPWBe3ITZ
E0b3ZZbYh/Ihyj6o2APbiifsDa849I7ebxRE3lompbe0ehhwCuP5CfbAAOkB9KD0kZ5+QP2P
qiTrB/SPUYqV3a4cWykJvQH0npQeeQgM9FDSiXVXoGWK8m5ESP0BkYLwjybO79/vIPQkEpmd
VNpNz5welV4Genx9cJFnTjmAXo6T5YEnMfU5DWcidDhAP6+e9PZMWmNFlxRxegH0SDmwDJaY
7A30dY6OxTBBj0x69FJhwsion0g/BhO8v0g/Ogqgb3e2TJnaDfsroe84i7HVv/7w/5PZZ/5f
vfcbDidGHj0x+pRArzLNDglG77bdeAB+VdV920C90sm+bNRlZm9TduvUe+DmSKUtnwwIULO9
+vTAQLcT5+3iDZdlBwZ+3A1WH4nHElEG+isVKIyiHEvJM12YEqXapnyQXo+KpT4rg9CnpPQ0
j4pOLtwxhe5YMWRQIL2IKn7f4PP4VhH6hCb09hAcE+kpC6FMMnrSbriJ1r6URI9Hu6Aw83bq
nb2OLcIB+u+NjimS6dO13QiRHiAsqrHbDYfNIJnjKcPYNmhqH1R6lnMcVVfQf8wMDDBYPvAX
6UdJpHdWY21AP0pAbw9BaD8x8h/WsftXV3/4q583SkavUot9jTck3YDRU6YZkXtXz5Qnr4ft
/urpUXuQ+XRlSdZjv663K3sn9x74ExR553De4faTifilrt6BZ2kAPZVlHy897DoWiedHAbpt
6GAi3w3nVx7rOdD15W6l33giPRF6EXipc+iFcuMt3kjhBi2yNCr2GtLNkhcvJpGDwI1NhPR0
tuiI8SsV+QdauvmZVOgxiFBE1zui6q3UG3B60m4++IClG9JuzJBiiffSXEk6kO6X+i6UYywc
oNcdU7DdpAvykPOh1pDrBv8TaA6VXiny25FUhvRhB9BjiLiPdgOXJEbHBjjpbQMFTd/Ng/O7
kFQ8BouPb4KltN0YScXV7/2/1v32/PBXv66CdINe11RILzR6BfRWBAKnIPit6saTV5FfXzVk
c+Ks1ExXPk9TZFr3K8ve8ae+B7a9cFlrQOSb3yXrzFeRnq6lVg+cd1N6sPrWvT9+2UOUnqux
ZLCMJkhwZ6jvB9T/yFK9N9DLyVIxEVuJpliN85bxxkOlpwIugF5FkHFsMb7ENNm3jvGU8HiX
DeiVtxLbiIEjvkAPmZ7KsUK7Id8N13kdlF5K9DSnShlYasI5ZkICeuWrUv7KNNGeqrEE9ao5
1jJYgqLDSGNWZ8WpAD1Tnr4bmg6LfASvhZBjGCxteTc2oAdfT9UyNYq0m/Y8C+iHsCDc/KfM
36P/8t5JiDdg3QT0qUR6zegp69KsxlrNsW64J6C/2kyifhWqs/Ye9Km6HVmwz/xNy96D9sAc
qq7O+Sg1H1WdS55qqgdStyU7+juXvAi9w3kjJfvWgYeYNwLthn301DFFOQiM9JwcDKneB+kt
Qk859GLKrCL0QTI9S/TU4woWT2HFSCt+J0FQT6NjAcqf40X+uVO5EZYbmkUl48z8kB6MvpB8
N9J2QwZL3MMu3hjKzdsNodroQ3LdrOpnnRGjZ5GeGD1PGaFOWSXKU28U4uedM8KRdwOk50FT
Lu2GRg36OOlhpR+1z5kyDJYPKMCyvf18gO/G23bz+98PNf78/5ABcP5134mqsTycwUiOyZDR
O2A+gNJXN169ehLTa+Up4IGd2GNiSd2erMs+C90Z7YG5cpcgv1JztLrxXNFAb6SiqakJ/pW2
aAeUG09C70npn+3t7TpWCN8M8oIJbalRloa6ClJ/rP+A0G88KD03S1HipVDokYT2xePHGumt
Blln5A01x4pkM54+EoOXRoTUU0Y9hBmKKv7cVosV86k4d1iQfiehNxpkFdBfFP5Kao7lc4PJ
6a222Py3lVUpHBt9WEA/oXIbiMpnJtLDRs/ajRDpgdVE3MHc0ROLYSNGuxQzesQdEM93Iz3h
p49I/+B8O+i4t0h/kMQgiPSB1VieJoiZhM5q7BB6qPJ+854RWOn78fnP2mBJrhsAPbLr05Ju
pEZvJZrpBEsf7QZAfw5AL39LxN6eiUNVs+nKbIE2I6R7YzfellM+6Sy6wj+5vfqzeDTa0drd
2lsIoAejj7aN9zz0UW48Kf2zxyzSg9ITl2eIj1Gfq4L6HoJ66DfupUdSURCa8NAbQO/bH/sQ
5sq3OLQGMA+zTvxTGhwrR5CA1L+dTxL9AQPp0RNFWosg9HTtQC5M59IpljgnCCc998aiGeud
s1B7DEovPDecXInrA3VxVBfOsRWSdKNnTGnXTVriDVkqAfR6QiyJ9Az019ErxVTf7q+kIeIY
NCUmCtoXmmNhovQU6fcNwklPo0usZWg3+84fgUhfFVSNPQ+xhWw3D7xCEI4cGao60WeLPnC8
ddv+95+bYwWFZRIjplICvZokePqQkVJsZRV7Iz14lgH0Gu+3O5g9bPblC+EcY9lH/UnsAejx
bq1mpeaj9ubjZ7q7u8YT8f5n3QME9DvB6JP1F/pRinVbbtxdU0K7aV16SLycwmqImVNCPUWc
KVLPk5+6du/+EbTeMRu890vcsZBy0bh4e2A/cN4T6e0yvSD0HGuMubGY7RoRLa8YR0LyDTj7
LyDRU++ULsUazVKs0OOXfkhPhF4AvYy7+YASLO2UXrfF4hVr00047sqwGP2MHj2SGaNnkZ6g
3h5shimxFF6JIYIosNp9N9cxfsSL0kOJb/cxWCLPBmOmbAMF7SkIedVQ4J0BlobvhoZM0eBv
n7AbEPsjQ82//u3fen2+/778xK6xI/YYBBRYEUj/MozeX6Svqj507txppG1alB7f0Y+Q7J1g
P9xQG9KZ/ycBdW/si/h+x0SDe5ZizdH7LYfPHD+D1d3akYg/7O3uHngYb2Pppq0t0tnrXYp1
d02xxbK3i5z0xOOB1xDmKQGHBpCYUN/1JTdQ2daPKv0AtJztmEToU1N66pYCoSdkFzIMLZFi
Q+oNlWQ/X/1LqDMa6Q8c4P4maPqC0JPZ3muJoYIy74acPJRqhgxLyruxyfRKuSHhSGVXrtwK
5ygL6XO9TV2IyFizdKV6FulJoyF7DVnpmcKD2FNPLBR5DA+0Az2l0gtK74ywBND7aTfIs4GB
0q85Fo59gHh7INAj7abFrMY6If8ICrVH8q6Wv2971/7nkncp1swO82ia2rULGj3FV4pqrG9z
rG02uF2l9xXpkax27upJC+gF3lfJr1152+31Weg4U5Ujs+EcbNlHff32wN2+ugJHZA2JfUfv
Vx8CxjPKnzlT1NsbT0SWBrqf9XZJoK+o6O/09FZKju/omiJCD+WGgF7OmuqhXlkGfku/6QCM
f7nbDvWPidBHBKFny81+/D41pafhsdDbOb+ejJIE2pelBI/oYhbq21Y/h6Yuom8o58xO6HGX
v/EEekos/hkaaMX8cB4ULnPpKcIS4o2S6U3lZlKJ3RkU+TI5mkIC+lVVWigVAn1awg0loHES
saHdiElRSDMjcR7TAzEM1s7oP0KEvBwSbod6Nlhe9xJvrg8eAdDneQM9cs3QbVXdvsvZG2sw
+t9Dxsfoj3bDX+lAegqkPw/a3/xfmW/GSY9AemqO3UXxlQD6FDjPM2LJXokIBKsxVgO+p3JT
VdVy+txVg9Hbgb6Klkuzh+iKEu33mRxH2W1/cnvgu+e1DS5bDQ6N0sZfjie7ioDxFtB3RmKJ
DjRHtfZ2XWtrqq9PXnkv2hVE6J31WCL0MN2oUbGX+w/sl7EImtRLqyVQ92GvQep/3I0hsyT5
CEIPeUfgfArxhhyZFI7D2hDHoGkop/IsyzfRX50iUV0h/QGECosg+kBCTyeMn3H0GScliAFT
eoasQem1ckNxxzoHMqTjKCygVyeoYUJvxvm0sF4weuL0JNGQC4fM8NeRWilGjeBXzp4p0m7E
aEH7QoMVzQz0yqTfx5Nj/QyWaMKqSiHS45IAjD4A6DmUHrS/2ZpfsLr6q3YnlxfAD/TGiClL
o0/N6AH0qivWHCjo1Rdb3XLo3EkX0GtKz0hPa8gWgsb0orShtjgkfhHS0Zx92A3ZA9uelFe6
WqAEj285E3tn5862tp4iweUFpe/uAu3ufwaJ/mFHvKKpvi3ZFr0QSOidQE+EHj1PROiB1sg9
2N27+8sD/ceI5APqOasewj3NlYVUT+VWKd+A0Mv0AwehDwZ6yqNnQs8KPaUmHNj/pZwbTkI9
DwyPvg/vO0k0n4iIegHeXDulQBw/Qg+kV4SeInHI1KPAXog3ktKL2VL8DN7+VHWcNWzIO+h+
kLCAXsWarchqbFowTz1TQqQHR7+upo9c5wAcBnrScHiMoBFsBu0GMoxXc+woZZN5RhUfhEjv
o90gwPLBg/bq6qoxp7/SoPRiyFSVy3Zj8XoG+l0tLe8au/yvPAm9AHpEIKQv3aAz1mWv9NFu
qqrB6B1AzwK9+sI3eo3+mVPHgSFnMov2IX32tuLDzpZ4qfHg8aTHg8EXdUWTTTvr6yPdJtBD
oU/EodADruOxiqY2AP24v7fSQ7wRhB6eGwb6ni545vc+/oKhXgQYj8saLdR76Ddw1UuofwxC
L2q4wnJDHnpJ6AOR/iEcmYrQ4/zBpP3hQ9JzCM2pW5agvoJKslKM338AXbGK0BNa+yj0MrNe
xQ+T/o5FWG+fKGh6bt5+O66KmuUhHRVhAf099cQ/UsJNelAvKP2QnhxLAfXXpcmSgP6gU7uh
iYIIn/cQ6QdpdKynlR6ezPYqDIb18908gEhfnefsjXUCPZDZL5JehNIjlbKl8f9qvXE/9yb0
0OhpOngmQG/OBg+m9Az0SEzTxVirKMtYz9KNBfVVVZhR5UZ7cPvFrNk+pI/gFnnYub46L6Vm
pWb4YHvz4eMAefqvuz9JrppkpFUAPVH6oiIo9NHIQNGz1t7+eOxKUxtc9JFOf2+lG+kFoSdE
Z0L/8EceB/5jL5CXYy1B6oH06JSVrnpuoCJSLwm9AHrloVdI79E1JY03JqGn+/G5g4CeB0+x
hZKRns03bJgnCZ9zKwWhh6hPN/ktmhxF80RoOEn+27RU/62U6WmIoEwoJkJ/Tddii0M6HMIC
+j8qoM9wyBSJ9PuoNUoY6Em72UdxxYLGQ60n7cbO6aHd5IlBUw7tBuKNj0iPGeCUOe+TSQ/7
JQF9gEg/NDZa3dLia7tRg2MB9M1/Zb1xjT6MfkwAvc4pTindnG52Szc+vhuaMHsVkwedQK+r
sXaYJ8ivbr56snq7s+eRlJyJPeHkcIR0bGcfNq09sO1OX6WHp4Yy5A9WN3ZDae/uhlADnAeo
t0YqqCEqMd5rAn1nLJHoeNb97HFnTyzRRn2xFT0B3koX0IPQdxKhjzOOg9APtLY+e9baCr4O
qZ6z6gnqhZ7OlhwS8Ym7f4EsNDuhf4xB4SmR3iT0nF8vcF4g/ScyGEEgPSffkGWewVs0S6Ug
9HgISeih5r/99qe04LQUlF56LJnQ82wpBno1XmolrMpYWEBvq8ZmMH5EzI0loCeJhtJvwO7N
6YH7QOkd4g1pNx6+m4MoqrLz0rWg+dNAwfM+jP4P+yDBY8yUv3ZznvT3QNsNU3pEGzT+XH/Y
/tPYqA/SK6BXxVg/pOeU4upmzB2h7iqn7cZTvMEp5ORVmlMivDbWsrQbovQmqYfx/usT8OmM
uqk90L6gbuR2WviR3WjL74E/FkOLd1tqOHiy/fTXicT4BUZdiO8E9RBuznQlKN2gKZnslyI9
KH13dz8KoZ1Qbnq7IomyegL6JJdi5aiRlGZ6h0IPQo+zBiG90G9QNmWoJ1KvoF5I9aD8LO6Y
hB40PxXS88TYwjhgVk6Y1UAvST1NnwWnBzSLPATS1al2KturUhB6XYoV8jss+kTelXgjZXo1
FZzOG29/qs0rYR00oQG9zujJVKT/MynSY2Ygxo/AaDNqqDWk3bis9NiEjJSuGeH7INLT1h5I
fxAjwjFQ0I/SH0FvbKBIT0OmAm03Eugbm0/qd+5DP0IPRo+cYlwgpAX0NHdEMPp0YhDIo0NA
7yfdAOFtyg0IfXXjiUsnDqEEIQw5LiGHOmkbJkpmwjoks48b+h7YdrdkYnLKmTjJF+E1pfdb
rsZByZEqhtEfcQTW9C7BT8NQ3zoQQahkItl0paJDAf2ZMwMDkURhPzZBWk0kmjxVj1SyaBc3
SwUjvZ4ztVcRelgrBaFnoJdQDzDv6bD0G9EqK6uyXQeOScuNbIplPScV0IvTA3noQddNQq/l
GzHFROYhMNIDq8WMEBlnFiDc0NgROfGbos/oJIF7Q7xRMj3GhBeays2nn6oL6Mqw3vvQgL7E
nD2SnuWGDTpssCTbzUE5I5waoiwKf3A7rPSOeiyGRtGQcLfvZggVVxJ13JT+4ChQbPQPfiL9
0C5UYwNEenjkyXZTNeoyWBKR5wW7PDH65ub/Wr11v/aR6FGNZaCvkpNH/I30zOgxG/yQi9EL
0Pdy3TDQVwtGb3J6zkJQXN5G6VsOnfj6BBLv9cK4cQ+0XxmemqxdDOtKM6zj/U1/3Ft7an1I
PMT4+42/jJ76IDY+HkUqPAH9eCzegejIzt7eAcLebrgoK6LxeAKTtOPPpHYjTPQdra3oeers
iUPCv5JsuzJOMTdn+CtgqTwzpB9Iy01cKPT4WwLpidVDqofVUpJ6IdWjcZYCcGB8Fwq+odCT
GycF0ktCzx56VGLZWimUGy3fUEnWTL55+xoWheHwSPBPPVNulGD/M+qKtfw0bLJRM2RFQVaw
fIo/kJ6bXyq07AvrAA0N6L/VkfQZUnqp3chks4+QTwxPjXbZQKUfQrKBI5Wegi3dSA+BBmO+
PbWb60NksPROQYCTHsoOKfAu7eb3WCTAg9ADcFG5hFte4Tr7JHlJ0yR+rm5sblZDhldbfBk9
Az2wWA6c8kV6BfTM6NOTbiDRM9D7afQO2YYkegL6cyjf2teuIUf0pXx/hwsqa5/fCOvwzD7u
Ru2BbxbLfZR4sPjh7e3Nn+2NoNep4gqAnIBeBAXH4pGOHkA9Y33rUgdOAPn9XZRbllAi/Zmi
LpjoeyDvtC51RfLb6psqolfaLvS2MqFPh9I/24v0A1bo4/TnunYPUFnAQnrKqietBf1TFIqQ
L4JwONaS2mdZvdcpN8J1GYz0lHIjKDsRehpItX+3AfSiJCtHgEOoh4TDqWesz1uEnkeFe3bG
cvqBIv9y2oiYIStleug5WNd4G1bxlRt9JbTr5NCAflVdGFLLVJouetqQrTXcHCsdlUPsqbEW
aTd2Lz2iLdE05bbSk7kG9VjvvBsS6Y+YjP66lWC5bx8k+Op2sxr74AEQ/ghE9jyAOwLT0IiE
EAQ8PFZ73q520r85Fp5Gj/P/iCWjxtr4a/lR/Q9W46vVGCXPCczo8QAptBup0Z8mWzz1Ttm+
vCl9FaXRc0ixn0ovfDeWflPdcnLgxGcuoBewn9d+3xmbwIA/PN1Q1zeXNd1vFCxv3ONApQGH
92h8EkLN0e3tLYfgqUGhtTUeb6tPRmMdHCwGPh9NjMMFE+kA1Aus7wGMV1xYGuhKNrVFO5V2
092P4PhOzPwe6OwvjNY3NSWjaIuFcpOS0Eszfevj3TZCv8SEXgG90G/0WFnpv6HIs2vxT+PX
SJ4XSruIrUwH6GHl4esAEXJDhB5DSFxIT/k52nyDGiq+aIlRgxBucDrwXoLQSxBnnCeOzzNk
GenFuFnGeVmK1e1Swxv3xjseKTygV0nFNZn5K6n+Sp5KuCo5qXI7TJKj5kBw5Ju5tRucDTyy
isHb20e9k832AaqRY+yn3XDgPFdjHzx4MAghZnRMALwAceK9wHAAKCRt0GUiwvgHX9VIO2vh
BdWmEfNETjfKPT5iF1bUGCnCdjojMHinCfSH6KTgQnpP7Uak0bsUeiMEwV6JxStoOfn1VX5p
Hqv60Lso1Fbfd3dXCX23obK8OOvMCe3TmskDf7tWXtfgrcPzW9X+mxPnig6f/OywXGd6E9G2
CojysDmC0gucB8WOgzYT1vf39MSIrkd693aWIcxGV2Oh0JO3kgh9R7wM0ZXJsmScu2JTIz3j
OceZKW8lCP1jQegtpH9GRVlA/QGE4QihRlRlsQjlE4koxZmxh16l4ARRem6KJUJPFwKS0DuQ
nq4gYL4hm6Vw1HMDFesuHFUvmmV9cV6G1otS7Fuf/OwyqzlapiekB48Xlwi0jZbow2qXWg0r
1AxHpNUylSGl/zMAPeWa8fgRAvr7YwaDZ+3GRvF5/Ihnz9R2AnrPZDOQfRLpfQyW+/ahNxad
qqNHhgDwowzw4O3QawjQGcQB86fBwrHIZ0n/18zQTr+QCxP/aDX+vfh4/pI3aaGzATXeMvZK
ACZCfxponC7QiwSEtBg9z5fyAnr6214iPc5gV78+6Qv0jV9f+hoNWHiJLffdDkwh54DeV5Yv
fpsJKmW33bA98Ls7ROHdEWRKSh0+Cl/8od6z5IbvOnNc4fzhop5kRX20o1+Obk2ME86TOBK5
wFDfURhhut7R29mVQMqBFOmLipZgou9oLYJFEiZ6tMXWJyui6IqVMJ/aeNP6GHFmqim2o//h
0l5dpBUyPUv1ex8vwWrJ+o2GesA95pRQBFkiP17Y06UJvbd2owKLH3ZdloSeKrGUjsPDBW2c
Xsk3pOMz0l/EqEEOJjsrLgJEr6zXYkLPZVuB88cA9GiVNWV66peVShArN5fCbpcKE+hn1ZNX
A8LT65iicqyk9KzdAOhtIj2CzjDOySHSI5QeVnoY7O3rOsw13qn0iMNsr6rO+72b0YPEn4eL
B8oMkH6MIL49r10gPKE5LQHkwPBmqDeCvgsGr0k8gJCwENucPHloRHyGJfyLE4K5gP24PIDu
znpM0BIaPR5VbJqO70aOHfGs03o1x5J78+rASbx4b0bffAJAf/X0IXo1LazO1Ux7VWoJ74nf
7whNdNwwZPyJPNDMWvnEZEGpp5VGyDRQ4qsbD3+Gr+PHuyNfAekByGcU0ndHKtraYl3QX6hD
dZxUm/gFAnjCekL8GFC8qT7R09v5MA7ETyyJ9IOiztg4JPoimOg78qOURV9WMW4Q+pRI3/oj
EXpYJLXlRgeeWUDv1m8A8u9EAcG4fqDxsuhu7dqNftrUlB6lWIvQk3kHCr0b6IWjXlhzgPRA
eQwQ/wCTXylU3so584ophuVG2nPkFCpKs7QhPUtAWILaf1qoJfq7oR2M4Uk329Yp0pN2I+YJ
SkZPs6VMYAd/d2ZYEqUfQkyCK8ISlN5ndCxrN7a4m+sk1KD0S1p6O/llMGeKVBoB8RLMCeAU
pOMbLXBYW/BvAef8P4By47v85v0rzfVJzhFcX54OcOrAGQGXB/LRhC7jsRjo9WzwtCg9p9E7
syu1Xu9B6WlOyQmMQfEG+qqWc5e+PnH1EAN9Ywtz+uGRPRAJfDlkTWnB5MRI8TehHcJv9gP/
MLenFhKNP4MHwB+9f7+6kTQa/KekmmfxtlNNpyL9RQLojx8fiGFaSMdAN9FrrotiPjbE+Z4e
gvoLyCFIMoqP93T1I6Fy586yfvbWd3f3JOJxYaLvSEC5aYNEHydvpRBuUtZjn1mEni03aKj1
Anom9aTfWKQeMI+K8QcwCJVBuyk8dsAEet96bC+PBI+DqmtrpZwWbqf0mtNz8g1GlmN8yJUP
kmUUQHnsZyrQ0iOO3iL04OoQbo6B0APobTI9K/VC8SegVy764fCqXOEB/ao+TWUo0iPvBiI9
Yz1ZJmm2lB3o942iHuvw3cBh6dUbhQhLoLln3o1NpEdk5b4HR0bxPxJoQPZJggfwsupOSwA9
/8M/s0pPPVP4A1is6sjVXrWLb6M7E7o3/yNB0XvyMYj1S1HH+ufkSUyBojOI+GNaUhd5lRry
g4FeFIPtC6KQR0ixrMt6dsdCuTlx4pAv0FdfvfT1ABg9I31zs0L6PbT6JlD182WUEvCzis6G
nJi+nyspr5sM2N3CEt/47nhFAmVTAnj1JbD+DLIMdjYl+geEeHOmCD/HI72E1zCtY+oHYJ4q
sF39MLET1ifakH3QFoWxvqcnfgXBZoVwzkO4gXITjyyRt7K/sAycv6IskeznZqm0kL5bE3qZ
coNsYx+kl/qNyL8hz0z0Ig0Sr7gCpE8A6C9/aUbV+6n0TkLfLwm9S7xhpIfIg4wzjDekMVEY
8g1KT0CPqwAZXexCemqgld5KVFwB9HLklER65aYXXbJUln3704gSPyY35NjwfJAQgd6aMpV2
eCUb6dElxaNj2XcDoMeyM3iEFUN4tyWbHUTgjdjcvtAc6zM69joNDBQpCOyifDB0BFVfEmlY
oWEcA6UnAGfQBrTjDECYjoWLDCL9AHpo+PgSIZTKPskWy7wxuhyA+N5YzSkIJ3F5AHc+nzTs
Wj4R+5PnTlwlpi8lHXlaYcwn9JZgnwro3eXYqmqvkGJH3g07blRNFnNKTpw7JArMXtXY05cu
nTh3UjD6ZsnpS0cY6MVKBUAE+HXlJXO/C++g/sk+8rbZxZGJykD+TgDPXprTS4UVFRQ0eWGg
6LiB85LSg8GPtzWdikcGmNC3LoHQR0Doef4HZHnhn19CNkEXTOy4CdEGmBzFLpyOeHJnUxN6
olAv7URwZaQTAcVLXT2xCgwdIf997zPKPEuP0dMflDn0EVLoDUJv1mO1VK/9N7F8AD1YdhsB
PXq7Ihg5Yo4a9EZ6QegB3i5C71TpRcYZMi7joPT0l+oB9BUXBdDrsVOuSYIOQs8KPS8t3lBG
PQXUs6WeCL0OuglpuhR9HkIE+u9Usa5UxRSnq9JDpBdDwgm1eYasU7sxe6jE7FhQerRYOYEe
Bksf7eY6Iiqr2slJf/ABsslIsREgLxfhGKz2krBjhDe+RjEm8AhA/ghUfMSiQaHZNSoCK0W6
me6VQrMUN01BUW9prKYUhN9xoRWmS5RArVVNChFzfDB6VvXZqMO6DitALVS85aVqt0K6UepO
iuZYvCAGei+J3gqwtHXHtpw+MeB20eunXN349dcDeK6K0lfzm2xDeob7HfN70F4/5SPfC824
tKChsrZvOcvxU5yY/ji/ow/yTJD+LkX4owfvVzUf+uyzz06eKRroHK+ngut4f7eN0AtiD2xf
iiRONbVVXCCV/jh4eVu0v6uVPJLoTSKc76QG1WcDA70PQet7IokmpFbCZE+/LLy4c+dOlGUH
BpY6EFzZ000zBKHcQLqvJ6B/zKpOOpS+u/WxVOi9CL1hvNFF2b0IRWD9BkBfBvhtq79SUXEx
SiI9JZ0ZUO+J9DRIXFtuePCgFG48ZHqRh0AJN+8Qo68H0ld8UHbWKsZ6FGSZ0IukBCb0aOpS
S4o3FG8GmMfUKSrtEtCrLPqaEA1rIQL96pS8IqnJyEgvs4qZ0pPogtQbQn0j4IaHSjnLsd7a
DRksfbQbiqgkB+UDDAYUIE/iCgssxGdJY4fvBsYbsX6/b9/vfw83PTqmqG3q90NH2mkLCfSe
QwVFUHFjNRksfyvpvjDTs02TUV9yfHB6JNKLki7j/EnCegn9XBWgp0W8Gx1Q8NFzv1QaIj3G
jlz1A3pv303zya9PnPMxV1K9Arabd8+d/Ew8NSpk2NQbzeufzz+a3/F8z/M9goH6lwgZ8acb
iOTnzIQnUb52JP/7uecjtZUQZwLUd/n5Gh7+aBBlVgJ4+o8WAmi+7kgCjdviF3q7Qeg/s6Qb
pdIfp+j4pvrxZxBvzvSXQbnhySFUjKW2JZE+ScNcB5Z6u7riSWSZJSHdE9TDRblz55U4zgX9
sWgyv6v12cASmeixSX20IjlOyk16lJ6vBHjgCNUEXITejfSk3yCqngoJpKhUAOhB6S9yb9fl
fsyfsuQbL6BXhJ57rAQ1R/K9Xg6ZnpEe4cSxs3RKqccXgB6UniOKPcUb9Oq6LTd28Yb6pgjn
gfQS6NWnYyrE4z9MoK9V0tNRqd2kx+gRccOMnkX669uB9tevY/CIgex+2g0FW7rGj+zyHB2L
h6SIynYB8qynk0sStwDlWXQH4leNDfkOFDw/hIADbOEzN1Yw/NFdqMe2tP+b1dVfy1wE3R1r
1lp3tZPths4vLOwYvP4kbDvA/EOEqwT2+HUjbpDV1ZS+G54vhcqqD6O3kXpB2mG6eXfgqj/Q
V2nbjVTpW6oE0pcb6g19m/Po0Qu+6fnzHcVPFuZ3kCfEX8FXmFU61VA5Acx/I3ttv7u72FeO
EyP2k591VX2kSKAZPrr9flXLIaC7+NIwD1vNuSWumO6siPQ7lRtF6Q/3doHSN1V0dKMSG28D
oQest3aSchOBbsMZBoTWNM8V2QZknIyS07LwQjz+DoC+KQHaHy+rqIDQv0TnBzLRoy22Ig4P
jpgwmFK9wVmkV00QLMTZBQFqjhmDhvFGWy0f/0jTRojSA+gh3QjtRgyMJaTXQ0ncmTcWoUfD
VeFbPbgI+CII6AnpcQGQT6cU1m4+SGIYCSnv3kgv4uzZWykVehos6EB6ovQw8QDpKbT4U63c
TIRIR8IE+nl1VJZm0hor826ESk+AL/QbU5TfPjjk0G4whUrYMF3aDbQXt+/mOlIORtH8iq4o
NtYISZo1+Lz7yMcZOv9giBA/b9B/cux5zB5BTsJgANJT2g21vCIFodlISnBFIeTtIiM9jC5C
11HVXzbj8DKrt6iVIqVMaDms3ltfruZYkUYvsyu9knBcVnpkFFN0pZ9EjzMHqrEnrn4mDJZ8
pSGRvtaO9IuPHj0hmM/NWVDr9tqOPXvSBrLh0qmCSQL9Fws/YTn/xu0dfeV1hO3BVz0a4AHv
R++jPnSIgR1f+IZR3kT6w8eLOjuiDMaXlrphlge4uyn9mTOdxMGjPQPdnYm2NhRtubsVyg0J
N+SEF9HEuLm3EEBfURGjsuwFlGrHUY3dWQYODlm+Lb+HxJ2OeD4U+vpkAsGV4hSRhkovSrF6
sJRTobd1TdlM9btxemBKD5Ee9ViKWuNceZyh1EwSrySEL6hZCgq9CE14q4MJfQqkxymFtRs6
owjfjUopdnN6SPoiiF576GmwoA3pOQoBQF/xwRWi9FD8VWvpytxrCvTaYDmsWqbSpfTAd9Ed
y/I8aqxIpTeSzQjondrNdqTPU+CN00rvNlgC5WGUJ2cNYIpLrWJxjXXogYR2EHbKpPcNpYd8
BHmnpf3IA3+kx9hYEuHb3139ry353iPxBvOqCOgNe43A+xbZfyVwniH/6tVz754gki4bcq3o
YQZ8h++GTPeURu/J6D1FeowSH8CpwacUS8/qJGw3JNI3EtQLSYnpZ40d6Z8/evRo8cXtR48k
zOeQkCPXnuf//LwEiE/CRKCoo+CthlG/bqK873nO7Gudo/bDzTs7Sspr6/Dap9J88aKeMV3Q
cOLEiYEzQHYCd1qayivM15T+8JnuDiL0p5IXegfOkURvwrym9IfPXAI2Y0ZIJyw3UG6Kup9B
gSHlpr8Lk76LCOcF1D8cj9ZfGY91wILDdssYAX3FNco3q2jL74CG3xGPJuubTtWXJaKIuZGB
Z6koPRN6rdx4EXp3PVa0T/24vx8qfSJKtseKD+CkR8+UGEpyuQsk3S8JwbLciI1J1adZJEHi
jQD6MrLd0EmFwJlEH0/1xkXof4ZirYn03DfFQH8Fj0c60DU9RTBEc2WoxdjVVRVVvELaTXog
LxIshXYj/scAf11F3wivDYKJzaQzMZKEB0251gNQdstgSR6bodEHqKRCpCA+ygA/NgYS/wAT
TgjkReTNH+DXqapuP+I/ZopF+uaq0QCgR8glKrbNVS2rfao86x1shs0E0IsMBFLfkZojtBRh
7mRPJgP9iXffPQFBX4g5pOY4uL0J6lBuTp9TafTBTVPCd4NzC/l/goD+0NcQ8SHSK+mGygqi
c2rC5PQ7APRiLSw8WQPKCxnHtciWWQsZPw0tWrPa4eHpKRRyGfiL785sXcL/u5m7yztKRson
iLPTWS21ImNoM8MiKr6msTNev/NzrKZYRzeTeMnlDaTX8o2U6DvHMfGvKZHfsQR2zTjvQekP
Hx8ApT8FQWa8Ihrt6T7DnhtB6JckoWeoL4KE3xaNRDrhwWGoh2K/E6VZJBYjk5h5fjyG3Mqm
pitITpCaTxrijfJWKoX+R7vlxhGEYKg4e/lCgMuxtDg2HkgvSP2BLqC3gHqHTC8IvU67xEkB
s2ntQO9okBUiPZIQohfJyQm5JUnCOudXavXGct7g0YnQc8Y8D6YioLcjPSUYnyWgB85Du8l/
W7fFhmiuDBnoc7R2k7lILx2WNCaccByxxWYOApQXx/wRJJt5ajdksKS0el6w2BwUVnnljG8f
GyPSDoQ/iOAbBfMHkWB5pL0d1ViXdKMHCv4eofUA8bEgoD9PHbbN1Xl//66VXuwF9Qz0zcTo
yaSpwF7I+FLOUR25p4H0gGJeQroXKTuE024bfYtIo/dm9EbgjQo1g/F/4MRJGUbv7a+E7QYh
CDBYKkbf3HjohED6OoH0EOXnNMzPFe94LlDeB+mfL84uLBDd3wERg1j+VGnq+qMFh9JvUgrK
W9AwSeA/UrJnx/Lc7I3vQyxtOa6xf/jm1lxO7vOSvvJaYPokg3pmqK5e0HDpNKoUdbXlfTuK
y0X147OBSOzUzs93fv7bnRXRS2dIpJGE3uT0JtJDuekn4aYtFofx8cxVYvR2Si+dN4e7OwDP
9W3UE9vfi9KrUm6EQi8ZPYC+J5m8EsONJMazsz5RD10IBhvkXSZjqM7GY4is3AkTTzR5AbmV
SrkJFumdhF7FVqaU6Vv3foG8SxBtJCBQDg3OOGcReSNCLHkuoBopa0N64PwBGOM51VjNlWKc
D6D0HJuJLHlujqVrB7giCel56JSzIKsJPQ2N4pQbcQ5wiDfQbqDRE9JDpP9UKzfLISo3Ydor
V1e1dkO+m0wYPaUgyO5Y2R8LSm9qN/DNO+aPQMf31m60wZKdlJwwzDSZPfKoxlLgDYYVijAE
nWB58A/otSLtxl+kp2osQHwwSLvhsbEtee9VDwVrN2SabDamgxtgr8zxeLJcq6WGJiHao1Kr
OmylhuLql7Kn0btPBPa8G4rkPARhyCe6UlZrOQTh5CGm9HRJ0dx48tIlocDU7dmxlnNXg/yj
nFxJ5QORfnZ2dk0x/R20oOww5jcw6GfCgu0nANQrh3EGmMIpoGFysrKysq5uora2trx8pK8E
DtDcF8XLOffu3Lk9d3d+YfbWzZszN7795tsbN2Zu3ppdmJ+/O3f7zr2cnOXiF7moLZT0jZSX
19ZOTNTV4YEmGxqA5rgMITxf/xPk0yNhO6oRAPeSHcv/cmtmZubmbE5x8fIEv5jhQ0XMzmFc
37nzw6bkpTPH7eK8E+0J048PXIBw01Rxoaez+xxJ9Mzo3Sr94cPdkQtkp4F+092KXDLUVInR
oxTbCmlfr9ZIsqKs4xnXZdlZzy1TwHioNci7BMyPYxoJLiHqUYu1gD5VPdZqllKTYp2lWHu2
mZV88xjUnLw6CuAp2wxQz/HFcgKsIPV2oP+SCH2hUOhJuFGEHlDvI94woadTA6ea4dJBjgOk
gmwEnN4u0xPQc/iwwHkPoIebnu2a0OgZ6CH4K/EyVOUmXKA3tBvpsEwP7cl3I5CexoSL2bGI
MjN8N9ch3piOS94CVN2t3Vw/D0Sn0bFA8wdAeVF6ZU3+fnt7dfuYLcLSAPoHBPTtR444Q+kR
ZykX6TLBIv35MbB+2G5a4MAPrMaSxtIIoLcYvUcoPddqYYtBBIHg96zmXMUC4BPqKuFeVWp3
yTR6D66vQov1REFh74emjyz6ANMNNkEIwgD+IlN6AnqceTouXJVIP69Qfm4Z3wEgnctDvcmZ
nb3nuBlXAQz5DPslI+DJQP3pDLUPB+3fKj/i7MPnHpx3akdKFv8FmJ6TU7ws1yMC+pzl5WKh
ew4fQixN2ylw5eh48hRU93g3Ab2Q6G0yvUHpUYolQl8/3kOE3lWKNZpkDx/vuoRNm3ZWXEJ8
PCk3kOjNUixr9EWdCQg0nG1DYZMDvRgZCIMlqrO4HEjGEIsDDQdqP55lsqwCtV1F6YPrsSj9
SoVepNz4EHovM/0XD3VeDWE7Fo+UVaS+wyL1BtIToe9h1FaE/qFQ6APEG0HocZd3EvQlUyw5
rBhA7si8+RnmirNyw4TewnmbeCOAvowZPQT/s3rmSGjDpfhCIUzXzerqHa3dZMjoIdILoEf+
gRwSjnRic/4IfmOPpSfthjMsXQZLxJLtgwQkWqIA8+SuoRQ0dLViRrgtwtIAegyOBYfOG/Wn
9Oykbw/Ubo7kwTgJt72U6HnylNfa1QKktsVXegE96zgg6RSAJmz/8N9TfAKgnum9dsLIkVI4
K5yEV9JPueH8TDPvhibMkove33QjqrE2kb7xXMeFS1cbj/J7PUl8/g5r8sWPHq25gd5Dp18E
pQey25aGeYX29O8///O/3Jq9DX3k5eSRzUV8uqqgkgJ0pQkoMnteANhvz9y4S6TdvXJmAfSE
8+KCfvjQ4SJG4qbohY7xCqL0Hec0pffQ6Ml+g7ugElvf1BbvAtCf04Tek9IPDMSaoAtVdJK7
hgk9MolJuQGh55z648efYYBgNBZpFXVZVGxbBwa6YvX18FvSlJEY6Hy0rAJaDs4tIPmIoqds
hNT1WCb03BUrCL3KoXcoN+56LJz0XUToge6AeIwVxBKRljb5hpV6C+gff8GE3lLoSeDRQO9N
6ZFPSe1VlGHJicKIstSR8m6kF8oNWW5Er5RSbmziDVdjz4raLoWkaeUmXCgO99Et7SZTkV42
xwLOJbxDuzEpPfg7YumNGARYc9AzledhsEQUJUYKYjYJOSlFjMHYEMq816/DQ4lQeluymUL6
Pxz8w3mMC6zOc6v0itD//jxXY8fOB2k3NB8cmkwqoIeRHoJJCkbPLVI4JaBrljg6u96J2B9S
dVom9wLsBbn3TaOX0G/wecHomz878XWQi57+5qFLEOnZYMmUHmLPhQtfH2psFkg/pRV5+G7m
PIDeoyS7MDub62L6Tqjnn+mcUIx/aO1YpFv+CYSflXGSU1hNGX5ZMWW9JwJAulSKIMTUTUyU
A9Z3FBf/r//NzMyNeYD3crFa92ZmZvUPNryfA87PLS8vimbDo4c+O36uA0EGAO3+zv5x5JB9
WBG51H1YsHkvjR5If7g7nkAsTVPZhU54Z1CK1aYbl/mGQm462qD/t3UCwjWh7xqAcQZ9VMJ0
M9Abr0j09MNuz1AvnPUdZQz09clx6DaoibbhEgLSDbz2/TzyVUO9fxACX0BA3+deKZxcdA69
C+ntZvpWmkjF7a1ieOxbx7D4R0J60m94pCwNDzeRngi9RG2p0Ft83kem51FTwG4KTODMBELx
hBoeQtNgTU4PbyXIPwq3lofeKNMqnZ4ZPaqxqOtWXLlYlr85yk3IjH61Tn1ouGcqA51eGiwh
3chOKWg3NkoP7QYpZibSM6V3Gyyh6MBDyTk2QHp8M/QAaM5BZ/yrUdvoWJt2Q72zeb4Gy99L
kV7EH/gsjKpqJk3GmCXrzegF0FuTRxwlWS7L0n8QeZAWLyJwBNhLVw4xe1rsu5cdVo2n4aHx
TKPXJN+g9NR2ey7YRS96YwnoZQoCzjSffX3hlyfo3CKQ3opDALe3yrAm5DtBfdmt3WATT6R/
Ojt71/kLhv3i27O3sGZnc9boJPB8T1+f0HxwBuBTAE4CU1NQf0hWx6qBtJ6euI4tCcIJxEnw
nyqA7gKCzrI/i/4A9JI9iwDuF8X/AiEGTH1hZua2AvI7gO6ZJxbI0+05RNstpOfviN3nEM4D
6J8Lv80goLy7Y/zUzvpT0UsIllm6EIWzJXqh97gSbjzLscc7sdnOJMIPOpcEoRcSvSejP9Pb
UQ9DT30Hm+ipW4qVG/JWcqglKrGdccqjHFCavYD6rvEygnWknMXjaFxCEA4DPRj+pS5E5GCE
rIR6X4slzhYWoe9Rk2LddN5lpt8rJ1IR0JPL5vLl/gM9KujMQeoNpIfcowg9IuU5/OCLLzwp
vXbeiAGGBO/5MUyN/fTTOKs4pNcL9YY7p1S8mYvQmzk4GudJxieg546pD8p0t1S4yk3YQP/E
qd1kJtIPgrdfvw7JngYMjg6Z5VgKK7bH0jPQu6MqUaPlyiuHkR15IMquQt4B0EO7Eclmclnz
BA9C0WftxjU5VlH6oVES6fNSA321wei9tRs20mMQrIhI03hvjypmoEcLFAG9lWgpe6wobpPr
sxLvSc6BsEPdVWrMSVDHlCD0yLr8+mv47v1t9HQVcQIGS1WNhdP/6qULF6Dr4+rmoJAblKEe
2k2uJ6V3yjc7PLQbH6R/gU1zXaeA3OVHhPK3bs0V5zLs87pz69ZCbi7fkPviBb7D97lr+O/F
Wi7+xf/xTbgweL449+ROyZ6SkpI+/IdCLTf0YuMXxfM3/7v/7uat/zX3xb+8wE/FxTdv3gRE
49FevHhRjP95LoOxM3S7QB0lV+dthPV3aeOZuRLB8trBzo9fSsLMkoxGvh7ovtrdOR499SHi
aQYOi14pT+0GhB4hN22J8Y4u3IlLsQrineYbpCF0R8aB0Z83JTpbW2GiB9Bzyg3dTwL9Mwz8
hvdSueqls34pjkIs9VARJYfLkgg9AX1iHGo70tAe0+BXFnB8KD26cCn9gIIyKfzAGCzlgfUm
pbcTevy1L/fDBNnPzkYh37D9ho2W+9E9hU5ZWorQ6wGzGDyItWRBvaseaxJ6wDxLRJSH5qne
HPiZJPQ4K6imWDfS/4yycKDiI+2GQxAuqpyYlXC1lbCBfpugJnQVmmGEJYn0VIylqDJGeqd2
g2EjQ7bZsey7uf/ALtFf52FR1AGLbGO0PwHmrQ2EdtN+xJwoaEyOPU8DBfPGfIH+Aeg6BVg+
CNBupO3Gkm58gR5ZN+aIKT9GX10tGb2CeknsJbPn4E3weFrAesJkdFfp9qog3w1VegH0J4Jc
9FywpUh6BFhKJ33juUsXfgkPJ01UyeO3WtksYaWn5liv5eD0817ajSenX4TMk2MH+sW1pwLl
b917YaE8kXzcVCxvEaDuu9aA38u5a85VPIfbb968A1BXa/7mTU3WvVGeblXgvjyP78hD41hA
9CeuGxnnb8/MjIgGtGog9PGvIcLsPBUdpwrn8TPnejqSUG/qY4ic9BNvUF8lC33beEQCtuTy
DkYvE2/QHItHpMotOLsuxbKJXuTUY/Z3tAJds2cMEw4XaPup/HqxLI5WKQvom5rGRb4xhokr
qPeh9BRnJnIruRLb64it9LdYwlrJ95OE/gBCD75g46RdvrGMlgLpcS+WYYDDNFdKEnofTi8y
b8SMcEHo+T5YPDNcID0kGtLpJacX88S5FCs99I5gS+b0MvPsLOVXEtCPayYcshk45PPIqpV3
I3Sb9Bg9NoTrhhKK0QK7bzvhPCj9Pmg3lljjbJoikR4lVpRoDSQfZJMkAT0kGPjkTZgnX/0+
Ks+OeQP9wSF4ZiCn+Go36LtKR6SvbmzeNZZCpAejF1FlQZReSDcE9GzQ0Ugvw82UkMPNVZ8R
sz9x4t1f/hIRZFD13Z20Lt8N6+8nvj4RZK5k2s+9sSqTHib6C5cowJ4D2UQcwkqlAHdoNz5A
7+D0xbOzTz3sOF5QD4vOLIvzci0W3xUof3fZIPMM77kQc55o6A9G+ts3b85hCxvSv3jKMH8b
xN1aOTdv3vIHePUb4DsBOUk0M3Memz+ZmbnrvDkHgs9MTs5MrcD5xqvHj1/tvgQRZmfbeBzc
HCIMDPJfR4HLp0RF1pPUQ9SHXt6UvMC5ZEK5USDvdNNTyE0FBn43wdYT7ewUyo2IuZEzBo8X
dWPEYEVMCzfKcklnCIyZSiCePhJnbyU5QJu+YsGdo+wfKqj3RnoQeh5mJSacdPXu9WqW8kim
x+RBDqBEDhqwnAbFYq4U+PpDkHrMGSRSz55602hJUG8o9GSCv3wACr0vpWfxRkRXCoWe5gdy
EKUwW9o4vUD6A5/QJQVUGdqYYytdCcYUVSzS6gH0nFR8UQ/tqA3TRB+662Z19Rulg3IMQtow
z5n0lIKAFljF27cftDksCdZd2g3NjtVADzZPsfGcR4nAG3eddvv1P7B+76ndHPzDgzEWffwN
lmmI9Ei7oWqsAfSelD6vCuBMHVNBIr2l0dMgcQPoRfiB6q2yxtqePn3il7/85YlzUNRlJpoe
YmU5Lg2RvroFQB+QUSwUnepDNDdWxd0cOv31BWqxEtGbMg5hpYABHsFmi2kh/Q7wdKfvRgC/
W6UxtZvF3BxvMi/gnX5Jir1YgUj/AoheTFtoqH8BSMe6a4N5AD5xfx/FxoJuIDyqrSzPP/U6
LeD3t+yyPQv7M/eKi8VHf/izoqJzZ5Y6x5nQww+/NCAwu/tCW9OHNAPwuLd481nRAJSbU2hX
7elkqV3L80KqNyeQQIKnkJsKxmmMHcEAcNkVK5UbCqofwGgpKDeWqV7mImCWeFP9tTjS6jvi
CZQOCOfrCegp3pKgHqkzLqiHh1MuKPTchctAj3GvpPQELZ1o1krU3CD0D7/Y29rKUC9IfdyQ
b2T3FEO6IPQM2nJQLON8AKU3FXpOuiTolnPFLU5PNkogPeYOakIvLDcew6cEzhPrF+adsjJV
iq0Je+Rm2Ix+VWUtrxzNjNILJz3AHO4alm4oc95skgLuIwfB4buhsGIF9BRQCWWGBXpKNvMa
NEWjY6ts2o0h0u8DpQcT9vfdnB+llql2mUbvHVXsst34AL3ZMeUj0luM3j5ellFe/h/FnHGR
VsRgnnv3l+ijRUCOcGCSTUZgvZ5Lbhosq1vIdJOK0Vfpaiw7fqDcoMWKcZ6QXgySXZnuA8Ij
2OypH9DbOf3cwoLbd+ON9HNg/wL+F1/MCZifX2bZ3qbbMLTjd8vGrUFQP3vz5j3xe4b6FzkL
BPO3cl7QD+aCdvOEfg6m9ei+yiHZxgnn8l7L+JUd6FnkySneI6bKDZ/rpuJrfBwCfVPFeEfP
1wDtq4TZx3vH60+RmHNJIL1Tpz/e2QFze2L8gpLaJaFnhHcifRF1xlbEcBdQ+mQyjigDCijm
rlgxYvBMZ3+iIh53EfrjZ5bA6NsiXfDUd0TyCeiB82ifohxjAfUcMGYXcCycR3OWIvSk9XT9
6IqtdKK+DqT/QhF6eGuI0D9uxRJI30UToUD1pVKvST2keugwynLDhJ5CbuTykelhraT5Usp2
zw23rNpTmiWQWldkGelB6KlZKsYeelGkdS1F6CkjgeYIlpVpE31ByIQ+bI1+dXVRi1CZUPqP
MCKcNfrB0fuDgwLNcQPKsYaXHkBvH0iCe1jazXVqjwKktd/HyQJAj6FUHgujY9Ed+wevciwo
PZzyAHr/vJsx0TIVlHfDthsIQNp24w30uwTQOwk9594YGg2KsWhEbSRFSc8YtEBe0HqRbCag
HuHylIuDKi2BPRw5wHqh2Au45y21lb66BS56NumnqMZygCXPHjl09etfXjiHB6XrJo44k+Yb
KslSsJkv0NtslmsLC3c8tRs3qYfMw9rNIrw6s+S0ufNCSzlOqMeJ4K5N0PGHeuLvsjwLqC++
y3T+abEi+Dbt5qb8KQDrhbjv1mfUXUDfbcq95PMj4jS5fQBpAwNfd1RQfyvA80LHJW59oviD
4wPjGA3VdCo5IMQbx1d3rALjROKY+Heps7e7+yrdR6v0DkZ/vLML40biSK2ERR+zqBBaI5Qb
jfPHn0U6ypIXOl2EnkIWkjuvRFqXlro6Cscp5oYmytaPA2gF0ovpJQLqn6Es65gf6yb0HH7v
v+SIqdYfd8uJVOy+72JCT0C/dy8mygKH2V9v1GQLEVMPpyVxcRFbKQj9lwrmbZTeTDczrJUQ
bji6HmqOA+mh05N4j3mBqQn9AU3ocVnBo8Hf0TT4+WsP9NpKnyGlJ1GeRHpqbJLgTmnFJtA7
tBsOucTmQocnRw0zeZh1AP/410O6gUhvTRT08N1gChVUkiCRHmBKqfUB/kro+I3w06QAeox+
o9ZYCfTelF64bhobiXPb5oeroGKL1ouiKxw6J2DRIWpPUM/uSyL2oo0WeG8GWEL9R0bxwEnf
cbEa/Lk3lgMs8bgDv7xwif6G0m7w73ZxbodQf8ezOdYjD2EHMi79gN4h37CVfnHtCcH87Oyj
5dx/MhV7O9Sb5dhUAo7SbnAuKL7DMD2nYZ45vkJ32lD/4If1Qve543sqQM3VrOnmUPJBTnGd
EDqrvu7s7P26t3P8FAk3X0VjFzo6oMNwDOXhz4o6LiR3frizvkPG3tiQ/vAAJkEhtBKAbVNu
hErvSEJojSNleHxp4HhRJEFnlCgXUimgmL2VVIsdiMedlhsh3XR3oEWqLUJDSToKE1c4RqEt
2QYmz3IMCTJYLlavlRtB6OmsoAh9CqDvZqRnhR73QyWWdRlJ6AXSa/mGZXWKR1DhN5cv9wir
PftxiNDv/uJHDfWelH43xBhlrWSFHnyegJ5EGjenR5WWxHdF6Dnb0s3ohUKPFGOxzupSbLjx
B+F3xtJfEJEdWBlFWJJaAxWFNHrm7eywpFh6S6xBBD2CauxWehRfUb2ldDKm89QoxWFlROk9
h4RfRzQZmqaMcqzZHLsPfBxOe//pIxDxwcMDM+k57QbVWDVo0Ls5lvugYPEJEukF0KMzFvzZ
YPSO8SNGKD22PQHg5vRLAfaE9mTHUVAvwFvgPYyTh859DY9OMKHHdqeF7YaA/rOvxy9cIuVG
MnqOLR4VeFVQsvboUU4ApTfkG3/txsXpYaWffSRg3iDzujhrQj1pNzlOmu/D6mU5FtKNAOn5
YlJt7NVZxneQ9duGluON5czoPRyUamuI9POGpH8TuQfLL0STZE0jcJ5WBO6Zz5vaYuPx+IUI
UXrE1tA0qN6vYyi3nmrrOAeotzN62DFB6CtiPT2XyHMjcm4sSu9g9EvjybaKSHfR4TNdHW07
P8Z0KEcpFsoNkoA9hJvjZ56h+bapPtKL5JtIHNlmNHMEbbGQ+TXU89RBAfUw1oOrM6kXi4eQ
C4Uews1DxFbyrak4PfKJdx8QI2bJVYP0yR+Z0EtOL0i9tNQLpGdgjxyLvEWFWgA922eI0P9o
Ab2nm14SenbpqPwcKtC6OD3/hbfIeCksN6IS+zceQE85N7QRGTBp5f9GYWNd2IQ+fOlmdUa9
mJrMmqY+IuMNi/RaoKFyrOmlx5BwW7csOXMwNwRnAwqcZzq/T0j2MN9gbKC3doMTgq+VXowf
8U9BoBHhSD4LaI4dwrRAu+3GU7vZJVtjgyi9BPrGk6fBxW2Sjs/oWDwmmSs5mlJMJafhtCfg
rCHJHumXcmqV1HHQR3uO/DMpgV4EWDKjP3lpHG2xOJkY2g3SMgXSl44EazeGegPt5rYvpbfX
ZMl3wwuRaR7Lhuv30ELlNOP4VGXJIU9m+2UpzsNo714E8Mu0oW25sF6cKjzLsJZIb5l3coDz
s1qevwqW3NvZ2dFBhVjyw8fGxyHe9JPx5sxVYP25MwPj9R/u/BBjv2WLrIL7w+cGEvVtbePQ
bchzAwnGwnkXoz98Bn6atlgvkffupUTTxxCJ8Gc6KU5eeisPU/gBRsKqMAQrzrIIVVxw+DiF
WUbyo5SH0FZWERuHc8eEetB6hnrqoULRwSrFtqJZShH6flboBf6nEG9aH+/+UhjmZWwC2mlN
oBeknrqn7OE3DMMxFm6ufSqslT+aSG8lISjxhk4YhrWSBXphxWGk564nUtmjNPaVPPafUlMs
gJ4sNykJPQyY2LxQD2O4+RMAeqscu729HTli6S/R80lLBBcgg4ym/ekHkH4a/TNNBORpIsxg
xeQ9xJahHkvyCeX54jspQPO39AW+3fgbSncR01sdq6X5N9DOPW7nZ9ICwRy/Zz4rb+CBhLYv
AletbejZ485vwL1PECi7vsT0cGshjOZdFD+dNzu3AoPHHz534pek0XNQggxBw595991LMOPw
ehcaPo+n5V+jdPvLE/IHcQ/vdfXCzy+gyAs7z7lL4++998tzcgIWPJ2fyUBN0SVbUz7vFWxm
kHydWhmk3Rikfu2ORPnbxabJ0gb4BtSvGVb6VFVZlGNzcqVz/p7or/KAenRNmdqNBnwT7IVA
D8NOwAK2q2osmTBvLZeLT/39Sx2/vEAr+l7Tzo9JuUm+l3wvGh0fH79w4VLHJbHQLYuAmq8S
v/x64ITxdYkaqk6dSmJj2rwDYRX47dfif86vry9UnGr7avzS151ff31pPIk/9jFGifPdcD9a
l76+kDyVTF6QP4ob+RcXLiCOgYKKL+APRb9iQn+q4ivc+UKcbhqPjkex4NfBEs8mfgF6Ep56
D/3Xge2QkEMbiGfagdvpq8P9hbR7vehufD96ZJz/cKnTgTvz/y5g9hW+4rSJ2AaFZlocWc8/
JfE93TGGjfy/RD1ZP4b8WzwulxfCfcYTuNLBA7Zhib9Afw630HeI5B/H2dn9hTvxs6Itacfo
eR2hl2LDDjXj89RzRelLQ+4JCP2smP0D6e8BEaa+UjlfHKTdWJz+ycKCzir2ovYE5bmk2ojl
SeY95Jv5W7duu9w43l5LouHCOX+HjZaGB8cO+E8g39spvfhJwjrT+Vv0SEFAj45ZqewQzs/K
sMqasO3U6b+B2S3D3gNWN2nopdhNAfofdHdsX9i7Lvv4W2cP/It426d9nfTqBCBgHdrNXIB2
8/z5opZsYLAMBnrDabkMSu/Sbrxt9dQdK2qwdhXfRevd2o3J69mvg26pFEAPeBfVWHJazipX
5Y6t8/5ln0nYe6BvMxlw6D567K1y9YKmwt512cffQnvghvCOqUAEf2Iv/PKB2s2OZbRU8br3
4v+5464rBsGt1SuTjVc51tuAk4PRIzdvLjhg3kPB4eYqu7leu3CYzs+SKAO/Pdqf/Bc2o18S
n18QzbAr0+FLtVvo+Hjjn4qOuSnfhF2xGUD/va45vNiEV5T9E1tmD8js0gJOCUtlqId288Kb
0u8oRhYOr6cvGNGL8a2vQu/Qb56gn8pLu3GyetFiC5Xee9loPWk3puPSIvRAd4XvsGgGi/Qs
7dCJ4Y6MJK/MSptb5tDdhCfyQvHf4c0Yd78ZQG+FFW9C0WET3qHsn0h3D+wRp3idZxmUh+Cj
3ewoBn8XXB7jTGRLLH4SkB+4GMtfAL7tWWc22JewjqBLsTz4vFusJ+1GIr+p1Rff40uCZXEb
QXigSI8oBb5HidC4hkvS3avZ7X4Se0A3S4XvrcT+2hSgv6GDv+d+Em9R9kWkuwe+kUdzQwpO
T6nA0G6ceTc7cm8bKG9l3+DWJ6lgXoUioHn2qS+l57LsGlg/1uwyzJh3g2ISdJssRJ5lKxRH
dVIxnb+jmqlkoLEv1oPxP6WTgWySKgg77CTdtyy73ebsAT19L/SYG349mwL023RGW5bSb85R
tHX+ipSfrXEkvsHF0G6KTe1mR66yUj4Fl9eLAJxS6VNqNxLpSZPxLscK+F+7zTD/CFye2H9w
yKU0XEK7uWuKOWS5EWabHIviP4KIExCJg+1h6LwjhNqaia3zjmWfyabsAT1CsGFT/tymAP3q
nJKjau5tyqvK/pGtswfmRExXjYwu9g85e2H6bnbk3pNc/kmug+dTzg1+h4mC6SxONlOp9G5m
L3PR5oVks4BG2hRIz1DPvht70yx7522JxoYL05PW0x1qhbZVujkfw61zUGSfyVMFiSvzm7Iz
NucI26ZPXwVPs+vN2gP3cuSbX1oerN9Y2s2O3BzoOAT0cyaXN0g9rJZz6cA8nRSQbDbnrd2g
PYrZvDZUgv0/SgX01Ef1AtpNjgn0hPw3Zw06L0T6WSPj2AX2eAjpuygofrMOieyrffpEK/Sb
Q+g3R7pZtSj9yohXt2H2tp/0HpC8tWYy2Htzh7UbgfK05nxcOLRNaiu9Pg9QspmVSm9Bfm4x
uqkEzNONBPBpaDfiPACBfd56yyj+huZQ2RONvTpoDbSfvzkhSlc1Ez/pNz/74rz2gPbQr2xS
2XJzGP2qQemzb/ybtwf2SOoaTOrhu5nXKD9v0+udvkuaVOKYKOhL8Be9rfTFYsysOWU2NxfQ
n1K7IaBnEFfGG1bnH1lRl6o4S5kKHh20DPY5t3KFpLUyVfLmHQ/ZV2wR+k3y1G4S0K/e1pJU
efZdfgP3wITspWjw99Q/z5VMfmHhUbH3vCkL78lKn6Z2swOCjNNKnyth/rY5TBy0HpvOpqHd
5K5xMA7r9SK6/p79PWV8Rx6mGXNpYn6OMtvU1L2BB0P2JW86od8s6Wb1B63ST2Xf5jdxD+yR
HMbbU4+Eg2IkFYu1nArlgfdUjl1LE+mpHPvCnD+Vu0wDSzBQ1mWwpxA0kWeWYiHKZp7mlIhM
43lbcr3B9Oe9MnFeFN+RkQcrU3vexGMh+5o3ndBvGtCvPtGUvjb7Pr+Re0Aq9SsFNGXQtp6v
PdVkPmcxMPFGp10i8OZemkC/CEGGtlXJBxLm73gJ96jOPk0F8lq7gYTD6vxTV3I9v8HeMZdw
XN6rFOr8cFadfyM/CWs6FGblyaZYbjbLR08vxlLpSz3TX9/Md/yNetXP5VWdvSiL1tdHjwTO
z1PPlH2YrC/qk5U+TaDfQeVYtt1TzVWOE7/nBfOLixSClmKOOJ8H1pBanyPoPDnwvd9H6Dvo
q3KS+mJ9xsvS+Tfq+LderCzPrKw0bJJCv0kNU3zWsih9VpZ8Q4/vNZm5vlI6IRj989ynGE1C
a2EBY0Seg9jnPE8P6XdQDIKMREgF+FSOFbb7FDCP9inSbrxjjO1EH9rNrKTz4hce7ymc9FK7
N8B+RH7Kh7NXtm/qx0AP3dssy81mMvpVqz12eMeb+g6/8a87t0GmYUyNPN/xYk6i/KM7LyDL
A/ipHEv/pqHe7EA2/RPcKxXI8+8RZXMblF7BfE5Apyy0mzveMcZ2oCddBssedul4f7GNYcIk
ar+2R9WqGrIfgjf107CoQx4nN43Qb55Gv7p6UyfeTL6pb3H2da/1SUJbUylhHqOiCNsFwwfQ
c359GkhPVnrS89NBeuLpuQrml4MCEVi7URsEifUC6J+6Kre2txhb2H7OleI8hixmD4U3dg/o
wVKbk3IjqgCbZa+kvyVTa9EikrUOv7FH+dqakqiHazE63AJ5xnf0St1j2E+N9KTdCK99aqhf
hMtGdEfdWiaxPiDkzD580A/q19AxRVZ679/rNxdCvunHqZUjeIaz4uUbfPw/14R3U2IrZbV3
M4H+T/qSpeENfp+zLz13Uh7qpbVO/80il2MFu0+1EINwVxgxUyP9U4Hys2rQbADSI+PMNnzQ
C8vF8G8xTNxn8dt8zzTYj8iusZqsavNGfwa00Xz4m82y3Gwyo7dGTa1ku6be6GO9RPmIpx1Q
T9pNrtJxUiA9Welz5TaBUL9IkfaA+QVznrgv1JNFxy7uOKFc+HbQDnVzOdiJSQZLJdL3qZc8
1fdGv/Vv/Iu3eqU2Y7CUPpVsJqNf/V5Pjy31dh6/8UfBG7MDytWhMGWPOiteWLijJPsUQM8T
BW3pxZ5wn6tmzc45g419ks7IouP8lQHooqf29lru3K2bd1JY7mnoIB/pJQX6IuaNeYuzL9Rz
D2hrZenvNpHQb6pGv7q6R3dNVWYPgzd7D7yoVEJewYgh4HCEpf45GOoRg2CMKvFEefTbirRj
GlPlTrD3hHpYdObc9VoJ6SLvklONKVkhVW8VZpFg0xLlNaqpzHpt3uzDfk0XKlc2d6LYpjL6
1R90629NtlnkDT/i1/5JSfU1DVav7PO7jxbWLOAPRHoqx64ZW7igflGSedJsfKYPekC9W7vR
w8RfiJGDIveMtgsQ6Xkb1Gxz9miYb8ge9G/6Qb9HV2ILfthMQr/JjH51znqdb/pbnn39a88t
CNRQ/+LRozltt0xRk8UEqnu2U4EN6tfkGMLbnImDbZ96k36XTOOl3XCQsRDn71DGDS3y8KSg
9Ms37ypHZU1B1muWPeZ1Jbbm7qbi/GYDvWWxXMk2BmYPe6t/aKVAavU70ERlaTfBSE9WensA
mobyxWUeXDI7y3ZK6on1nz7oRHpYdO66mX5uMeZPGUNKcnPhz0kl0u9RVy0rWZjPHu5rRshN
3eb1Sm26j57+4LdWPXYx+85n9wDKlKpuM8UOnOfoo3phjzzz1W+c2o22Wq6hbZYHVOVaJD5o
+qAd1j0nlbzg0bJohLWScLBd8DyqPlWCXclabbKHOvZAroV+f9pcQr/pjH61RNdjs/2x2YOf
9kCf9JevrExTBE6uQ7sJIvXQ4J+4TgOLxfMC5nNs1Vdse9vfhWlCfS68mMt27Jeqjc5OYMUm
RaZxuX5dU1k3cfZQpz2ge2I3uRK72T56TrG06rHZNvDs4c97YEQfE6V1e547tZsApCcrvUO7
UQXYuRcOVKdt3b4bayMD2e85JpXkFnN+vT3XGEgPo6WfSL+oumBx+srCfPY45z3Q96oqsa8C
6Fdn9avN5hVnPwByD2gD4srw5OL8o2Jnx6xfnyy4uzlyEDlpXmReoPkjbBvcQ6uwnkbHGinG
a3dZnHdNKVnECeGJZzV2R51uAi/Iwnz2KBd7QA2PRAbM7CYLN5ubdSNfnOUkzYo32c+A2gPa
hLhSU9A3b/pughIRYKWf07NIFJm/iyxMD0SnbVOFJQioz0XZNUehPtVcwfDdMM+Zxl6DB/uU
mWilpiHrtMke4moPWMLNZobcvIKsG/knv9MViZos28l+DPQe2DGpaXBpncdoWa+aLJVjxUiq
HblPBJm/t+gXgJNCuxEnAcZ3+CgfyZ4pYal0tcqK04BIS7CR+h11uvVxOOubzx7e1h6whJvS
7zed0G9+MRYv8Z6ux2bFm+wnwdgDi5UWB2iwRyP4xZwB3Um72SELsOZUcRd7h6yTQrtRWK/G
j3BoscHunaZLkH1xCpBYv9jXoE9Ww9ku2OzBbR7cmgDUbG6X6ubHFKvT2DbrGiYr3mQ/DLY9
UKutKivTlS5a7yb1sMfPY6CIIPNPMaTKXA6oX5udfZRKu5FQj0xjaDeiBnvPP78eBss5Df65
Oyb0ZxkztLJpTtlD29wDFuhVbrKF/pX46PmP/s4iblnnTfbjYN8DJRYprimQIwcDwm/QFyVa
oxaK7SjvEWCclnbDUA8mPytibea8Z8tKMR8bKKAvN593VpPMHtb2PfBqhZtXUowF0hdb4s0/
ZY+I7B6w74EddZoIrAw7JRw7qd+xtiBg/okKLHaSfpPCo40qJz1KT/EGtBBgH7hgsOQqbV+D
9ZRLK7OtgNlD2rEHFq3jo3jzBfpXYq/kl2ldx2RnkGQ/FO49MKJ7SldWSietzDObp37H2h1k
XWLNLnuQeY8AY45MSGuRSE/ifODUQQA80hLuLZZYpQVYhrJkPntAu/fApJXb+yqEm1fF6Fct
583KRPa4yO4B9x54btD6ldJKM8pYiDIK5QH0L1Il1ytwB9AboQh+kL+YC4M81hNsG0zoF4tv
PbVcNjgnZQuw2WPZaw/UWhLGZmcfvDp7Jf/lXP3Kh7NW4+yHw3MPlFh+S2CooeHAS/lUcPmF
uTUeVZJqSUxH0fZOKka/mCvnDt6SvbUBWF9SadWOV4azZD57IHvvgT3ai7Wy+EqEm1fG6Fe3
WW1T07nZ4yO7B7z3QHmB9RGBXk+12efPF+8plEdn1HOaPhik3MhzAON7GtrNmoicp0Ksped7
Yf2OWkOXh2RTmz2Ms0exzx6w6EDd5qbQW2eVV2Hp5L/+nWVFy06byn5CfPfA4sSUzsxA73hB
HQE7c3lGeazbCwtmDIIvuSekR2SCMwPHxvBzEVsPTyXiDtAoZc4edEB9SZ39WU1k66/ZY9h3
D1gVyenvXhGhfyUNU+K1zluf32z9KvspCdgDz22oSiLOE43ygPXchYW7qaQb5bUMjkFgmIe6
k4vwM/Ld2PV8hfU7yk0qv1IzVZedD5g9fgP2wIhGupr5V4XzrxDoV8stmT47Yi37SQncA/9U
a2o4KzWlpOIodAe9/6e0kP75Do679FkyQwFdVxyFQMEHzi0Xn9dOThsXGITy2WM3e+wG7oE9
lrOy/JXh/KsE+h/0WK2Vqeyxkt0DKfZArtGRRBShZrphooTBPmdhYTk9oH++wzcGQcL8Pc3i
4byxF25LJhpKTZBHzaA2q9hkj9tUe0BncK80/O6NBPrVGetUl41CSHW4ZH+PPTBi59MrK8NT
lbV7doDSpwn0z6HdzHswegnz5qgSFG4XdH59eV2BdbCK00xlX/Ytye6B1HvAEuiHb7w6nH+V
jH51dVGLN9kJsqmPmOwWtAfsZhfG3NIGgH2aSE9xly6gzxVjxNV4Wfl7YbrfU1tZYCfyOL0U
1GZl+ezhmNYesATqlVfTEvuKffT85w2PZU3WTZ/WcZPdCHvg+YRNsWe0H55qqCv3m09inAVQ
b4XOY2J9rhhW4hLkn6zVTk4Z7k7BSkoL6rJUPnsUprsHSqwDaLPHgdsvH16ZvZKfxveWflWa
lTvTPXiy22EPlDjFFAHDUw2VtSNBeI8IS9Z5FNTn3nXB/PPyicqCKSeN50uHiWzpNXv0ZbAH
Fi0TecErCKE3sP7VAr0p0xdksP+ym2b3APZAbm2lm3IT3g8T4NeVl3joOcaoEmD9C8wXBPKz
t35PX+1EZUNBqYvEC01+MivXZA+6TPeA5TcpfZUC/asLNdOnmmLLx1CX6V7Mbp/dA6D2Ew02
x6NV9yHEHy6dLihoqKycqK0tLx/pKynZcw8Rls+f7ynpG8HPI+XltXWTBQXTpcM2Q435IMNT
kxNZYTF7qK1jD0zo46jmlQr0WwDofzCKFdm+qXUcS9m70B5AybTBm4rbcJ9/qKnxxXTHxjXT
BZXl2Rzt7CG2zj1Qbh1ota8ms3ILRCCop/A76+pmOFvlWucRlb0b7wFyyEz7U3M35vvdUsNa
f/ZwzB5XL7MHjEJsw6uKuNFI/4o1eirIGiMbnr/Mfs3eN7sHaA/klpTXeRZTUwP98PBUweRE
efYwzB5JL78HdhjA9oqyibdOMdYRejOVtd68/AGWfQS5B3aMlE/UVTY0kALvzfOh4rCK3zAJ
EX9kTzZ/MnvsbNwesCIraxZeYafUVvDRy+dQYlGt7LypjTvQso9k3wOYHI4SbF85LZRl9zzP
sorsIRLeHrBmSq2UvHqcf7WdsfL1b7OK0yvZyOLwDr3sI2f3QHYPbNIesOZtrEy86kIs4eyr
1+jxJIx4s5raTXojsn8muweyeyC7B0LaA4bhZvKVF2K3DNCvfm/oWSMh7frsw2b3QHYPZPfA
puyBPstYOfXKZo3YBKMtwehXV29aFersDNlNORSzfyS7B7J7IKQ9YMyILZ3ZAgL9VpFu8Dye
WqfA0myeSEjHX/Zhs3sguwfC3wPPLdpac2dr4PzW0OhpXxjWm+lsBmz4B2P2L2T3QHYPhLIH
jCSzlZKtUIjdOho9RRbXWibLqayhOZQjMPug2T2Q3QNh74FcK5J3axhu+Jpii2j01CFrjWJZ
ySZZhn00Zh8/uweyeyCUPWBluqxUbgnDzRYD+lUj9WYlO1owlGMw+6DZPZDdA+HuAYOvNmwN
w81WA/rVP1kmy2zjVLhHY/bRs3sguwfC2ANGo9TUN1ukELu1pBs8m2+NAczZdPowDsPsY2b3
QHYPhLgHjCb/0q2E81tIo6fTzv9kTPfJIn2Ix2P2obN7ILsHNn4PGI6S4ZtbiM9vpWIs75Y7
FtLXTGz8+5B9xOweyO4BvQdy+zBeq2FqupTSPSnIc7i0dArzuCbKs60s6zpMaq1uoJq5LYXz
W4zRr27bYeyqn1zsTflkpsue8Zb5/dXf2yIzNEYq170ygp7n5bUIKH6Fq662dmRLh2MulmMk
V8CkreHphrpsGEmGaG8E3NTs2Fo4v9WAfnWb0Tj1kws4M4xXqYdgiC1sh5oxsibd+8vttka3
sdEZnuHzT9twu6O8cioIwDL9uy+zPcCysnwrtoT0VU6lNU1xuKAuOyw3fbA3cb5vqzRKqfPN
1vHRq8ziEeuzVfMTmyJrRFSnCyD2w8w4lNJ9ALndVuhBMzsGM3z6pek0S+eWNxjV/Az/Qlib
10w3TGR0NZI+sKxvy/IGoxCW+lWXTmaxPr0dPWKcPEe2Gs5vOUaPzGJjXPhPDOlfltGvrRkm
3dSfUdsWW6AzYR0vX76ENKYJ59YWZARgGe6+l9u8dHKLMPuSSftO4uG4E+XlfSXPF5+X9I2U
Q7R3jd2drszOVkyN9SbOl2+dRqkty+jRImuUrn9aSE+Mfngq3TXtkm5wtIn26nQfQm7HVOOV
17bZYZz+yxfPXVD0lNWaESdNRVlxOsO9tIGbY3ahUxupKah95SrOBB9ScpVCl/FLVtx2e6TS
PG/WNGyRIk9qvH1VW5g4P/G7LSbQb6kIBGvffG80HfykdHqitAVpHwPLXkAvJg7Xpf0gvOEe
uk/NK66tsexU88+ZPfNvmYCmGDuWawewhtqS+S1w5fz9i/I6u5Q03PAq34LnlRaZH24o/zb1
G7FQW2DEqv/EZNQNPiGYomrd1uPzW85eKY6+HwyF4qeE9MTo0wf6HC+gXyvhz16GUyi5jWP4
lUrFopBcmxpebFtwr3Rw8lFupSXMl1bu+WOGfyHkzb8psRU+SyvTKTZsMAjRw/2TBfOllcXp
v+jnDRrrC7Jive8bY+J85Rbk81sU6Ff/aJQtf0JInxmj9wb6NRa2aubT/6zSliyPT4cAIOk+
pLgSmczsWa/yCb80yKeYW6d5aunE3QwffpM2/13JpBFQPvkKoN7aS8MNmfr+to2oNMaahn9O
9+1+w7YzcX5rTA50HdpbznUjnuH3P0mk3whGv7bGu6Y0M9rwAyNNw6v7/DFYTGWoqHBZPnDi
2IRC0OHKLXoky0/cI0teqpnc7Npmn9pLpbXrUhXuTkpaP5zVb7w+Qjac/36T6EOGf2arfjxs
SP/K64gbBJAbwujX1ljPaMjsjZ5l4vvKdiRT8+H/NrPnvMzwElCILVHFxdItaHNwvdYnWj2p
mdzMumyugumCPZntf2Pr7+ok1G/qM9+gj13YD2P0w65MbqHAStu7vVWB3s7pXxlAbewxsjGM
fm2HAO3MPrXPWfF5RdVAITdleKx9k6IQm1spwWc6w4pFZjtuI7feo1SQ0s2jxnvk2XD6+Uu9
km/l6aLgFShPG/sp3OhHs+H8FuXzW1Wjp0Pyd2Z70U8j4WyDGP0az5ivyfCD+woLsvx8V0Yy
A5ptKQqxSo8ofW1gnl7/soL6hk3Sb/pEDWP45ffSE3HG2BpN1huN1ut/PCOvcmVyi1kBjE9c
hiwrs8/qy21tjpz6aUwi2SBGv7YmQDvDeDxRkN1M0UB+ev6ZJeLKDI8GUYj15Y9SSxguz/Bh
X/nmORLqh1M2B6wffKx7Srq5IaOOtgnbcxrdaxvxzF+TxzBbGLem30Yc8VsY6Fd/Z+7EV1hI
3LBDbqMY/dqaAO3Maps/MCN7BftRUPMMEVYUYv36dHZItJzcUpnfab7ENVkbbQj/pCuheTHN
Z5Zqsz18afbT6mJ8uU+3KTtsZZzf0kC/+kcT6QvC/1i83Hue+t4bxujXchm0M3Qr/g98Fb/p
KphwCWVYpAouxO4RUFmaoXqVCsc26/fb5OXIdNidDQKGpv0aYDN/vfeEELR5FYbUH6pXuoWZ
6rGlcX5rA72d009t6dzXdI63jWP0ayIIMkPdQhRkN/lTyjJTTYYW9+COWKk7b6WRnBli5pyY
mhmyCiJ4UsG6LJU+L+gmM4xXVdRP50O2idssqoIL7ZMNUccyPIwy2HwrSzd4GT+YpY7pTapf
hXaobByjX1sTiQLLGbzV2JTdL5vbISsyQDItBQYWYoVtuSbDs1xmeyr0rSfEiwjTTyb0+Uxr
Iyle+XcMboHNDaF9frbYA+8wZlyvTGzk6TSEo2+LA/3qH40sy5XS17wJewMZvQyyHM5QERHa
/iZeGokrjwytoMEdsQLnh7fYBJ+MP5vPhQoSnpIm9lOmoRMpX8c2gfRhq05bDNQ9no7yrfLb
WL5lfZXyDd3qQL/6OzMWbvgV+cA36KjbSEYvgywzrHFuekFWFIBTood9g8COWOHVnL6R4WNu
vc1viUJDWEgvQpE2mM/TXhTHUOnrfnn9sp9pcwpQzcjW9VW+LkC/+oM4YsV6vYNvNpTRry2u
x7V4c3MLsuIKIkO2E1iIFZ+vggyvZLYezBNiilJeOOqNODoyPcWmtZ/+xA899bJI+Xrf34w9
qCnZ4rrNFrdXyqNu2wsT6cMiQJtx2G0so5dBln1pfTj1RjyUd7MKsiKCfjazZxjYESvC0aa2
/gcrrdfM1dJwKpvrChdK60mvrv5PfLLdAqNsNuND6/03RIlFss/czHzOae7ljd1sy0s3eLnb
7lhJ2q/18bWxjH5tjattmQZZioLsplQ7RME4Qw9kcEcs41emlwgb+5HZyEcTGUAh6N3iFBtW
l8FcqhSiV4fAm/OXTd/38L2NPCLCeqzXAehXV+esmFdctr+2hvoNZvQqyDJDZYTN1ZtRkF1f
BH1gRyzjV2lY+BXWhyzgcVm9CQ7cXw90rcuTlcHLL+FLkTd17FSuaZ8vzdA5nMFe3shNXw+g
XxX2XbmmXtc60EYz+vUFWW7jfbnx4OIEJKESZ9jUtRrYEcvlmpo7G/kBeMWPJd6MjZbp19Vl
kdGeEGfcEC5F1nNa2+T72GyV07deA93m9dDo+QD8xuxNKH1NqcSGM/o10SKaoXtxZnMKsutS
iYM7YvkhX2//vBNOZ+jcNbyxkZDr6pvOCOdXV8W7+9peXL/EuaHEJi/8KcP99qo2f00YvX0U
ycrmBEK9xMHgfdeNZ/RrwnyaoQyeuxkFWSE//98zO7CDO2K5vBCKkSSzZ7mhW/MlTIqpuBke
ietJQsr0Nf1OXK9l+Mx+ApuX2wqGGcqmme7ljdv+tQH61d+ZTbKhuY9DPRI3ntGvM8hyEwqy
jF+Zdu6uBkcTE7bUvP4Gesenl17zhlL6dWWbZgwp80wxNlp0CvXztxEPriaw0ItfmchszlvG
+3gD7/D6AD2aZA1L00rDJrZ3bsQBQo8RAqNfX5Dlqgga26jX5fE4ovkhU5UleEYsnztestNz
21zfROVkQ8PG/K+ybqK2vG/Hy517FjeY0ouOsgwv8tYBKSV8Kn9NVdR1Hvq5Zlplzesw10y9
sa8R0K/+wB5wtUKP/lvnsRBwtzAY/fqCLFNN9XjZ1y7s7pm2ZQZ2xIpW4OGXKX3N1BaYR5Bx
ML3kt8PTDXUl62Z39Lo27qS7rrLNOnB+dVVYOF9XZ8R6DvHnZrpNzfPXqZvjdQL61W23zTpI
yNF/6zkQUtwnFEa/viDLkAuyXKoryBCUU8yI5TD0unVBEt0pt9I8eF4S2b3uXlNQu748YKbG
GxbusZ6JwuvcqaIgG8IHZYs+pK0MW3onw8N7nTt5g+72WgH96rYZ2yl1U2b0bOBBFwqjV0GW
xZkdEaLdOKTIYqEMZRhTkGpGLBHImvVB6eo3tSGjvET+6dp1sLxtVN7bqIEwQv3anBrhD29W
QdYmHU+t80jM7FO6cVu/XkAP843Zq7Dyms2kz4zR36OPbFqnmXW1QabQSdL6wz4biQj6DOMl
U6pJxB8zzHCTn5MZNUacn1fpdEFBw4Z8FRRMTZeWmi4MSBkZel3pKdJ5cfpldrh1XzGGfbN6
eB6JbNKNeepb/VHMbtiVhs05lb65QO8w30y9Vi0bmTH69IGe1euVqQyPCkG7Q6hpi2pgphH0
KWbErvEAvvUoN3+yYL5mqi6E7IcXqO8WlGr1vzQ3wzditYTAeUOs9KIZOdNdT8/3+wwnEIvX
SM88pLCeLYb7z81GnpWJ1w3nt/iEKa9PjC3NcuW1Ci4Oi9GvL8gyJYVe50dNBK1nSmwDO2Lp
meygR92RKYZi2Ipi3MMNtcXrfEnp3G1Hnar0ZjwS5Tt6aRuhQ66vBr46X8mnqeGp2owLysLK
uSEnqXR28ivbps+U/mr2rEOgy/zI3dB7vG7SDV68vSRb8xrFWYbG6NcEk8swyPK/5TttbK/O
2lruuqqBKQqx+ID30ZPNmEjpok5pXQjXLg7cyVWVgEwvPAhFNuJ9EDXwTAHC0J6HMx4j/mZ0
yJphlSult1+rMqw4HF5DoF9dtZVkVxpeGz4RGqNHkCVfQ2coi+dwh+xGUEkD8biIUpoh5Qnu
iOVHJ8pfkymGqekQBSFVnZ0MM7dOXD80ZAYFhJYbUI0VtZoMa+AiXUitmkyvmd6EgqzNPb/y
upVhX2OgX/3e7FtYmQ5Bdw3lGjE8Ri8nC2bqtgihILuuCPoUHbH8Zvz/27uWFUeSLJsB8oUI
4eAgcCGt9FXauVb6AC2EviAqMjKrklBAVkrbWc2qFwMFDQPzA7MZZopYzG4W0+pohoaEhqTA
JeaamaSQu9xdds3fpqOuhspKfx4zO3b8PoWRIGASvdz+yNFZYVZPV0UL8FIIhH8if5iiKlnJ
lW7Tc56n87ma/s/WO2QjPQPDOfurkjlpyzmcOy3KeQr2VdeRUKe2lL4pUdEfCllyP9uvekC5
G55RCfrsHrGHRxA7iMubKHLTCf1+taW3lO+X5RAVm1jusBuzkpX38mk73mQ4HclKmsGfeSDv
hhLkwvIAuDOu9OMjxW38xjeHTRm9lhL9bvMjEtXWjjjLMhX9/s2kkKWOlOasJEU23DIFWh8W
fKJXNolF5d97sh9M8JHBl+LLw+XgnHCsWcnKj3LADmajV+le4eY/7JRD1tYM2UhUZXDPtEky
JkG5h7aV6He7T5F4p1aYb0pV9GaFLJ9UrYKcJHM83awE/XVHrLg+m+ilB6KW+oqSGzgfV2JL
ykv00mS05PkGDo2+T70JXlWrAi7lyFvbWbJ4eJ6hGS7a2/KmvUS/20T32oJ9igVRX+QypSr6
YyFLjpKkFa3HsppoGJHNtYxYU9ONXKJFbWGaABwOk7dm9EcRdvKAd4v40WYlK9WAvccj/U0F
YjGZ3pFqoQBvcj4ISjj7FJsrXjDss6NPmUCWeHiLiX63VZk5x1/z61mWq+iPhSyZH5fSGVdM
3SBVgp5Zy1E3nJ+r6O9rJB9ZlodBlyJ0NB/Ry74E3Pa8B6PLedLhRDL9lMk4ygBkXYZsNNrG
nzBXFhPEcg9vM9HvnEgv2dCt3BrL1BAlK3qzQpYHT2gBMaqqV/meOWF1/cFcohe7alB+7Hzy
FJCFNvWByE30ZiUr3wQ9x9yoKk6XWThpl3Ql5uJo3uE9acg6/tx/ZZrF9Ie/iiNbTfS73R+R
0jd+wzVF2Yr+UMiS6wtVaTa5F5qKWeeWoL+aEXt8Li7Ri1VaWwMk+Vb6RQVyE71RklpypRr1
WfaJST4WOmSlbjn9xlxEmACWfXjLiX63ig5Hp9G+f56i/yAmGZN+VXQjU48V45A1S79X0X06
/hUu0YttR+e6TIT1Dr8Tb6WfqJyX6FXZImaAt0p1urSsG/X63Slrf7WBrHpjYXbUIR/iQPT+
gAlu2bzNvn7biX63+RYpQBtUlAJpNHt4it6E6GVsShj8iTcPftdm24zXNiqsppERa6ro5eeF
0TAVcZLcZrRHISfRK3PLi/bt1IFpxQvMQqe2djlkpxFWcb+12TwvR7v1RE9xlhHzTZNLF5ev
6FUbJnYhS1lHJl9XOGVqZ4af6TpiTcIr6yV6YTjSr+uWj+hV20ZWhhat/HRji7LB6W9Tat/4
Z4scsneRgL5wzJzWzB23ksMtIPrdKpIm22CfbAWKfn+nAuOZk0d+CLg57F5KVH5j3ja7R2xU
WXNNN/UTvX5ps574DDP9kFA2M/2bqTESt0zb283Sm5VDtr6PKFP8Ls+LemF9j1s9iLkKKjnc
BqLfbb5EPrQaW9CyCkVvVsjy8B1vvFZUoKu+UVrNba2M2HaaboSi1+feXERv1LbxRQ5YWvCC
MgAyMzJ2crMPWtUhInHCR0pVhu6X1pttLDHdiNd4jppvGtqPpApFb1jIciW3StMoFVV+QZ/Y
FM/zcrWg6JO3YfVVxExeuDbcyrXKdUBa4ZCNdhgJxzbIeTts9JI01jJj5PQLGhloWYmiNyxk
+TVT4mVLfVWCnps5r5kRe7y1sClzipqJR6rPjiAQ0d/4cih6ZWb5wfz8v1ZFXhXOGTOvulVn
GX8XNuHEaC6s77U4GTYyelaYbsQbOf8TqUoRNjHQshpFf3DIcnlXkI2hQ9Youo/jiDV1xtZX
UrEqojdLXrjuklHV6fTdyYpUVIZsi1oBxbeWaFBluPjY6iSpc6a3huhJ1I+ior62IOpUYVKR
oj8UstQXlGpCKMOsgUNW9QLnNqTWzYjNY6O3nui7UkPPmcpbJ8hKfSFzQ3ne5PdFfbDn/CaI
VCQO/ZEtct4i040039xHfLJhp4C0/pwzJ3p6VYp+r3yjQ+b6V9/z7DdWlMC9GcsRewuK3mcD
TyeoupFM2fmLVtqE2fbdZodsTM6791wfBXO9VXq4RYqecPtDGhFOv6Y1JKlK0R8cssGvvKlk
1hXO7CNfZcRybOgmztj6pKUw3ejHuIreHSbhleoj7IE3zH9o+t2VQY7ri2yvQzYq58M59815
o1D10XYR/W59bBJ6IPvOX0x0UlnnVKbo93u1SplSL7n4yRVHrJHb7id+X/L2Eb2+7UwQvYGi
V47YOyZnaJc2MnKxOy11yMbkfDCxyGwjJohlRL9zHiL9SMJGifrqFP1eBcJwwyYMusJJBedu
eWTDdcQamG4c8VxtUvR8ojdr56XvGzGrXtROh2xMzncemRqJN/9rONo2oidLfTRPNuw0J4OD
p+h/CKoy/rh4M8pjZxchNEutUd8bvApYTEVvP9GbhUDK9gO+XkFv5erhFqfvyu8MjlXOeJIX
deJbNA2ntY1hMzYQ+4h+t/k1JuobE+7FU/T5iP7QWbDLFA9ME6vaVLk3YTtioegTKE0NFVN5
fpMsrBuQpgpbcIP0W+eQnUX6T4edz1bkwkZXvoVEv4vXLg4Xk6K2/nzXqVLRHzsL/guP6XlF
CM3KX303knw2K3pRJoZrulEfX8wyBdyK1GbF6dUWVFfTF+4a7UV1oT9g2iF5C6yuo60k+p3z
OZo95fd5ZgLuXNE8nqfoZS88zSsnHmYk+T4zcl5UATVuFLeBI9Z2RW9A9Cqo9Y3JG8q/yphU
RsXpW+WQjWbfhIvPzG8k5gjUdbidRE+W+mhDktCtzy/3vqx4ij430SsjLpeHlUNWy8QqWYBr
PDBxxBoQ/U6alxmUVuyhvPBKPtGbuWBU9d0l5yfP4M6hR4ZaKBZ37tUmco2cfv7AsmCb075i
K9HvNi9RUR+O60+fqljRHzoLcpv7aZtY1Xc9M4p7Jx2xBq2ImKabmole7IH6cfRdsbdyOMos
qEr6Rox+3OL0r0bWOQ4ChRzbjdadDxe/WWidV1xvLdFfivr6C51VrOj3e7NAa00Tq+oFzmxb
yCtNfL6aTYhe67ukEMqIX4Sn6NlEr8KWmKykktSMfj7X366tFkpBX/Oi0QJm5KNmAlqXGcbk
vhYT/W7zMepmqd0py1f0LJmXML1V9COzhu1GK+fFrJyWlHqsjNjjW7WL6MtV9IpGf+MteNW2
0fAXfObdzPjDTZOjCzgs5oQNOx8t5nmbFT3NzPU0Orn9ea2ZspUresPOgjomVrNsmgdz460g
+iWDbUw3lAIohC5RKtGr+HZuwbHhaDYy/4d7t6Y7ZF/70e+bYGqrdd560414Qeffo6kQoasb
QlzMeo9epXpFv1d13vStxWpWaOS8GPU1yrP6uYperOP6TDdlEr1ZmxfGHlnIoTn29DLWXuya
XrT+YTj+dzuDbex3xh7fcKUSxd9/Hb2swDImG0/RfxfPnPsxlIWFm92obAMZSCkjMdMmdPie
N6iETDAIvxlH0Yv3rq/9TJlEr/bYQti4zIvcNdchO4zZdN2eTYUqEwfVZhv94YVXMde6368r
lYOn6AXR57XRE0HKUAufO84qNiYVKLNe4Fe3j6xtjavohaOhn3ufNL1AiUSvitW0gJmMEqBN
AWec9xoLnQ/7f1gu5+2OujltbOsf0WDZsK74G76iL4DopRQO3SeeeFNGlrTUGrNe4Pli7riK
XlBtfV3tyiN6Fez0M2846zlaqYX6w5qjm8AgZrVZfm/Bppl7ALlKL/cNa7lAPH0qXNZiveUp
+n0xit6ws2CWiXVo1Atcx8Wbocu4RC+PZ+i8Yg+V3xPac50RXqlMcRPtS9d5oMqNq2+3TRrS
SSy9xh/cAs1bHUd/PsU3DzGnbC1FLXmKvjCiVwEy+tXRFXD71EBIs17geRyxYsVyiX4iXro2
f4yAXL/jqj7Rvxo51+ti+8Y5ZIdxGhg/2G+1kaN/G4qeXnSl6O79588r/6asSdHve0bheKkm
VrlYXG40mmYaVqqw5hK9I166NiO9uLm+B1yf6CWKi7qIm31fWb+uxuCn6Gy6i4VUhu7bbcj5
WyJ6ovpZLDMwGFVc6oyn6O+KMt0cOgv6zM6CKkbGvXDIqrKJXCNx7lRJLtHvBNpBTX53WfVd
HyJtolcJcH9lE25tJzTJIRurRhz6s/WNyPnbIvrd+jEWVRW61ZrqeYq+QKI/dBZk1l9NLj+m
yiZy82f+ljvWjk30sjpbTQZiucnos6su0auSFtyqE/rPUcKRKWqhWI+IztW8WEQGlZ3nfpSW
AE9ll7wZ041EdNuL2W/CRZVW3NoUvWFnwaSCwma9wHM6Yk1s9LudcLv5tRSwlPFFjD6OmkSv
sOcWqauMSxJv1BCHbLzeQej2mLKnXhhz3/22iH7nrOP2G39slr+jIyLix9Sn6Pddo86CPy76
Eb2qOjjMeadXPScbUrai330RT5+V9WUyhlrnyC/HV32Q9MoUm5Wd1n+Kco78k3nVCy2sdQ7q
zmNWW3+2uh2rzW05Y4+z+DL+Juh/15ksBRxTn6Lfq86C7CKEKtvq7KtHlaDnfvPmdcSaKfqd
yiCovmewtKRzPKZ6RK9QbF3lrb/X7pCNG+fD8UPrUMy7C9+YohdwrfZxa11VBXB4iv5VcGwB
28vhEsqHyq0er2rOn7hS/ZHZv26X2xFrSPTPcqDdqhtJSrM0KxdZi+iNegfm5Ycizq/ZIRsv
axPeRoZUbORukOiJ6r14xdZqusryFH3BRL9XgpD7xSolvHuIRJU87zNsEnK2aZRI09jPuCUQ
xJ0fpEvGr7Q7/KFnESttQYfoVTYyt3dgEUSd+xrqy6qeAKgL43zgcb9Hc79/Ey5wk0S/c57j
EbXhuAKvbK2Kfv8XqW+5XeFWkivdweRt4qmgJf3wcDXBOV1oMwhffBYwAlnO7x0uKqtZesCI
6cXoXf94UyUr9XOwmkAup2dgt6rV2Pi1DhmO48b5/jNX6jQKSeOHuU2i31GnwXiopT8u3Zhb
r6Lfm7UKUTz9/mNJVZqXRThixaKWoels0+rPhzArt1++z/3Omx+DuvSrH8iVKzexbOZqScnK
ZCJSPU8qz157i/vUEe/+AAAckUlEQVRgw469vQKvbAG3SvTUlOQtbqovnerrVfTHzoLcIf/f
CNNzeV7mLZn0iI3znjBvhD/YiubpVNsk6PS9ybCUHLm7oTcaL044BdyPHmmWyiR6Zf1obUTg
hxocsm8XX+3LbmsBZM/7+AncVZ/7hg26wCrWf4qsufNSdV/Nil7ViwndT8wx+PaefOCzbQeF
OGIlBwoeZW8z9Koyy+j95wdF//zYDfpcgOVmuMgielUW+oU5cA06XDlkK3SLdy9oPpiyvwcb
BGDeR7llot85m3hUfej3S6yAw1P0mlk0WrbK40FmBoB/zJaCZQO3z6YaqcOLyVoSbMjpPHJa
Gs/xwrQR4i/4D8Hsmb8mxbflPGMg21SyMuXtlcYocXFF4OuO4uEWN1XvIGEMbproyYD8dLnx
l0f1PEVfBtGbFbIU82ZjlDBekCNWLmKparmRnYcpP+zEnHIF0/vhcu58aOLq+yxOz+iG1a6S
lclM7yiNwZIlpge/XtJ8/9Mty3kakhsnejLVf457ZcOgrBZU9St6w0KWfI2qzlipPFrTBRs9
T7amY3o53x/cuR+M4/UvimT7YNEf6FcxiwIqIuT9DLFr9h1mOmglnadCXStwyN5d0HzY+a+b
DKk8H8mbJ3oqgLOP9SIgI0U5dS3rV/SmhSwNF79yxBbD86qBis9tUxt98tXnD2+TabG/yfD1
26+59KLYDjNQMipZ2RvNRuX+M2BOCllPo/ySxbOL7XzxPdfoMF+zoYeD6IXwHMYDcEK3DKpv
gKLfmxWyNJu9KpezsKjViZSEZo/S5LNEh5kwPalLlaxkxhvJaqEl/7iecRkge15PoygFcHad
S3fMcnjzal5MfhC9QMHZ9C6pPsNoajhDm6Do9+r7hVuWzIQoZZ3gYhyxCnAp6R9NHqXR54ip
56fmjRqVrPwY90WWwvnchoalZ8gm0PxkY+I1afR8MXo4EL2CzdlOLj75Ci+B0whFfyhkyY6T
ZE+vXyXZFLldSknfYT9Iw0+QkYeptmujkpUqSa30n/87D9qSHbIXFeepzBFo/jBEIPrjXHW2
F9WPwmWxqfPNUPR7WTXFL7tqylZunAU5Yg+fUNIrybUN88io8qM3MnI1NY/LqEKRPClYlvoT
t+CmZDyV6JBNoHkPNH+aziD695VNVH/xxevOCkylbIai3++V7bxkG0hRGbHnZjJpxmC3RKyc
u1k3lDilfvcYDVVxSWoZNkq56S6YdpFv0nVQrHxSsbcX3zABaP58HoLoz9HYbAYXVB+MCsvy
4Cl6nZKGOZwF/EKWLP5SDPU3wwdMO01etX0l2TOQkyE1qSE3qosA8+PrTZ5UdmstlZLB9Y1L
61vRGbKvl5E2wQBqPjLrQPTRRbjZXHQpCIOiCiPwFH2JRG9k+GXxfOGO2HPjjUVmekl8qaQ8
NClZqZLUivSNJG+7ZjXyis+Qfe1firPZGhGV0fUKoo/z1/b5MuGioHJnjVH0e6NQDgbT/1YW
2bzJC3NrLTOevNpDv2ebMkwCpIqqFnr9W0x6kf09E7GCM2SHFxUqKQtmhYjK+KiA6C/n6fqv
o4soZL9TQEGmxih600KWumtaFbEv1hF7IB5pzGhrXfY4ftLIkh5xo9TvShd1dVwZvpEU0leZ
XMymZX8U6ZDtxevNizYzz6D5yykDok9aRuvLEjgU1+ddFznZRzRH0R8LWTIXqSblOFKJLgp0
Y5+nxEhy5CbraD55tYepplGp9V+MSlYq30ipRVjfB8MoJOj3whyyk4vqJVSU8K+g+aRZDKJP
Xtubny6qnZHPLGe4QIMUvco+4rf51mJCeenSyEbqyHDMjPfQevBqD5Kmj3CZlio1kVaqHu+Z
CqwWqiFruqqWEe8Rd8ovkfsL2buoXEI0/9PtVpzPHgUQfRo+64cEqs8XbdkkRb9XJRE7JfCl
2M8KWMipRCMtGuHiickvDTvcObxGWkyXUaHRqhyxx7FRvh5u8p3cqnOWLL6MpySaf4SaT5vl
IPr09b/+06Vbljw95k2OG6XoD50FuXLsOl3KZezntnNlCEpFkW6r5+6j0qOdVPuWclry9uFN
eb6RlOFQXV2G12dF5Ii8DtmEeEpamE+g+fRxaPViYU4v/uHbVULPCvNoS56iFxGKvsb3s/Eh
yq/ZKXh5KBbOaeS68k6qX4w/4tEgf/zLO0NJ4XCcyvNK9TJ7VUmbeUm+kZQhUT6BrzyknuWG
lNVqJWsCdC/jKal7PSJtMscARJ89RTfr6WUVc3/cM2JXnqIvnej3A8mXbpEpshvJNRm1GI2A
uzjpkMLcVlG/ktatrOrsRiUrK3XEHsdEDjg3NOhnc4fscH5ZsG3pbRE3Dxs9T23Ej3ac4aXX
J+yYSNaGKfpDLYQwKG63P7TiLr+9RE9tvxRLl290azn7sE0F6eYtozwHlaSW28nJ3Yrl6uDm
sPUMn9VLaBW26G1A89cmcnFr/Nqd2vv3zub7ZRxX6PJbDjZN0VOJEGUD8QoanBdJv375PL/f
d9WnQxjM2ma/+fmgG5bphfqNMpe/lpWkdoX5VfouN97VxCHbvSx1ILwcKHagsXxB9BogUb36
ny8zM0J/zFRPjVP0+72K4Qs7hQTUT+XFfJOPHa6MpOOPxUaDVpWz/PmwQfnzjDQDk/j0dS67
twH+p1NUOgC3OL0qisa4by/BZuOPf4GY12EwNB7RQokOWn1OiLYMFyxSa56i3+8PzbX8QW5h
/JOisAyDBGNV6xx6FPXCE6c7jDUfd3+g+XCZpRGUrZ2599bgiD0Oksrs+sbDVmVPaztkvYSP
an/+sS0Dz8OmhKOh6LVBXX1KiLYkC45+FmIDFf1+/3pYQW4++41zKAbnmvmpdYj98phTzow/
ftUex9oOdHpHsgoyS46pkpVd3nMqU0hhbRt546FqNTDb+TIcst3RZUQExVP+VHDAGA/xdh0N
omeM1+r/LqsY05LUtuA0UdHTij7uX0vPWNU7x0r+C/1tj8claXHcJwZwZx8ZQ1n9of92Cgr0
x5kgdaUBjGmP6klRXXZp4tQhMypOr575uvmzd1m3TPhmnqHmGbMYRM8Aa7fbbC7bUNFsXQ60
6rrwFX1QCBteu8jwpDRHTFWmwHs6bhV+eovra89g/PdnmQ7ufMoMPGcNfo6DP4xOjTGuVkI1
KVn51Txc0Rj48xPNitOrr5Ar0mCQYLMJXXQVYc5GED0TMGd9okVpkj78Ah0LTkMVPa3YE1tS
lU6urO+e/NSLKs027zwzOw9/XfYHw2ZJ+5fpmRfRv9rbQIbYuzyjRH2O2OMomBWnVx8CGSLp
tZ9gswk7QwTaMGkLzlguYMIv+5Lkl9UoZCwUvTvQ/QnDZ6mZseeS7O693wpl/upz/e/vK9Et
s+pBtu6MB2T4bqffH80GXm9Y46/nDUbz5XnFa/d6tzLl2PzMm5bsCJZCZHzkIqo4/V94z31l
g5okhLpR8O4LbxfkPZKtR0PRm4zsdptQGoEsOLPsOjiHfMjzL4Er/16N6Uat2DOHl98ZvFzH
5Sdv/J6k6Jbf0iiLne4GCZk0DKArODTQ8eX05L7ALFlpEpNeONWr4vTMLOsX1V0g6WHuBgl5
iqST1qD560vz8ggQvQlqu53jvCUxSzDO8ocdY+v0WaUyRS+XWiSELej0p7+kgfPrZNQ5/6he
1KfmTyRx50Xlsz7KFRwZdAY6xfCUrdtfJP6Wi5T/yXOuOzUL5/boBVVx6rRnTPnvKvPi8tmT
guYp3ePN0f/YNFvYtp4Fojce2fXHhOJKZJsZpXqXmq3oxbIdxmyifrDszEeDgTftDXsTzxuQ
MaKzdKMNuNx5Pbb5BOJ6HYwXsaergMWv3MJfznXDYZIcj3ovwEroKIfyT/5mvSc+OyrmkO3O
ki4V9B9hmjdmKxC9MXS73To5BsdP60XVd7m/ZTlLMuuqk3GS/yt17QbjBoj52Pv0Bv1xZ7Fc
ukHg1/gLApe2yRljF1SVP01+2olHJU6oQ0VOk8c/d8h6SZZ5CmzbwGaTg6tA9DnAo3BL5z3m
5HyCN0jkGqzs3kjP4O0v+7pS1eApbu8UVdzd5JfajrBSEM2f/5Qh+5YYZhOOX1G3LBdRIeom
H3wiBifZghMuZlqx9ZWuRP2b3U1H4+VlPdgTCfnLzshLa46kfxsceY7AbN43/DVkJAaGj0+n
iTdI8agHo8c1TPM5iQqKPieAdDplUSWaJ7XCLBpNdUNvRkYQsoG4buAHZIpwl4vOuD/zGOaI
Rr8gHq45CCT7X8Olt0YKbH6SAtHnx5BicLb3iYbFcJnumW3OCsOTAIG6EXhN9L9SeZHvW4j5
IigKRF8EisKC85BULJtCx9I8s3UvLdwfCDQFgWmyTHJn/wQxXxA/gegLAlJYcJIds6E7r6mo
YFPWMZ4DCKQj8JZUmlLUCuzCAVsYOcEZWxyUdKX18yDRWu8vZg1xl4FxgECTEHhNyWheDlCc
slBqgqIvFE6S9e/laCNxclRVoM1ROE0iBzyLLQh4ncTArqD/BWK+WF6Coi8YTyHrN9PkBMcA
5npbGArvkR+B6VmlpHNN1JkiNap4VoKiLx5TCsJ5TLY7htm1cPIvHlwBCLQCgck8Of/aHX1E
nYMSKAmKvgxQRRDOZpgcSUCu2drLT7WCCvCQ1iLQS05/Jf/rEGK+JEKCoi8J2J2z/pTsmaW6
Z30kHFnLYnixbASG7822osUeloOnFWLmy6IjEH1ZyNJ1t9tvZ82FItMamVQgxBtEoBvpBna2
IoL5h+2mxKV485cG0Zc7BVZrL6l/giw6PtKpUH6DbIBXthOBtFBK6iY4/QdKU5ZLRCD6cvGl
8gibz8k5syJrFiGXdnIa3uoCgUGKz4oaOHxEzbKyWQjO2NIRlgGXv6S4n8D1oMQbQODuvOlk
xITp9n9GyHwVHARFXwXKZK537hL7UQkbTgdpszdAdjf7it1ULR/075xtNevv5u8Coq9sCqRH
XAp7PeJwbpYJbX7xt1laDxuKpXRQsqwy9gHRVwa1MNdveqm9m5aIubSZ8W7x3XqjlEAEipif
ODDMV0g9sNFXCTbdy9msvdQO0K52E+lbpA28c6sQmPTTmoVT5e7/QMR8xcQDRV8x4ILrnwZp
SodqJCAQp1V8hodNQsBLqXBALqnF4Cdo+cpJB4q+esjpjpvtx7SQyzAMOjME2IM/W4vA6yCl
WhmxvDt7XCMvqg7OgaKvA3XB9ZuXtJBLEYiDFoStJbqbfvBuSn15EVPpjr4iyKYmuoGirwt4
wfXO9wyuh3P2phmzjS8/HC38aP2a9z+5/fsNgmzqYxso+vqwF9VwNl/SajwJCQSDfRv57jaf
2ZunOV/DcDn6N2j5WokGir5e+GXa7OMgXQghwv42abNdbz0cpUYNU47I4HELLV83z0DR1z0C
woazfvLSV4oQ9vDOtov5buhpXzMibMjZ5D2hKmUDKAaKvgmDIOLrt9tJerACySKkU90Qebbm
VXsZUp5ChSdrRFI2hGCg6BsyEMT1681bWvl64dSiEPtuaxgAD2o9Aq/eOLkdoPTABnPqFoU+
Io1hFxB9Y4ZCPMjK+Xt6IA6FXS776ENoPYO24QUzpTy1UPsA52ujiAWmm2YNhwy6/DpLj1+g
UBwUu2wDE1r8jJQRlSHlw+XsNwdJUU3jFSj6po2IDMR5yMg7EcIeRXEsJtJGv9okI1ZettJ5
QH/vBlIKFH0TB0UG4jz30uuFCBtopz9tNCPg4axDgOw1QVpClDTL91YocNBQQoGib+jA0GM9
b39OreatHF4LmOytY9OGvtAVkqfuOV9ReLi5XAJF3+CxEcJ+u+1leWelsod/tqHkaMtj9WaZ
Sp58r701pHyzmQSKvtnjQ1GXq83nTIs9yN4WQm3ie1wjebLKf3ZQXb7pLAJF3/gREg+42W6G
2cIeyr6JLNnyZ+qNMnL4ZD3K/pCmZiuW0K0/JBR9W2bAynkcZH9BC7JH69mWk2tTHv+akqdu
gINHZ92W1XPzzwmib9EUcDZON7VB2yEcIuigz3hTyLKtz9GbXVHy4bL/tllByreIO0D0LRos
mTu7ffCuLUOKxvFQLaGtNFvrc79Os0MoVSmOT1tI+ZbxBoi+ZQMmLPbPmy9X4iAodcUdz2DH
qZU023bz4WC+TG0coj4Yqc3ltw1cr+3jDDhjWzhm4pGpAtqPq2QvAu0h7dvGt3U8r4aQlySP
UPmW8gWIvq0DJ7NnHSL7KxoM0r4O4mzTPTWEPJU2mH3fIFS+xWQB002LB48efbt17q+TPaR9
m5i3umfVEfKC5O+dzbbd6+Tmnx5E3/4psN44+6wGEId4HFjtq2PQFtxJR8gTyY/2Djyv7ecI
mG4sGEMVjOPcaZC9CLUfvLWAhvCIJSLQ9UadrELDShlIkkcpSksIAorekoGUZpxNN7OI7LHy
oLuYD4YlEgku3VgE3ry+BsdT68pRd7OGucYecgDR2zOW4k2I7O+uR+Oo0peIv2wsH5fxYMNB
/0pm9TGEcvCKwgZ20cIOphvbBlSEXjrO47R/LSRaxUUvx6PJXRm0gms2CIHeYL7IqiR//NSj
VpXTRwfVaywkBSh6CwdVkP12oyvtqWHVeOSB7RtEzAU+ymQ2XlyLwD3kQpGQRz9vO+kAit7W
cZXvtXF2utKewu07SK4qkGDrvxTFTo61PutEz/npI6VlWL0YbvzloOgtnwCUQqst7QXbzwco
nFA/Sed8AjLHj10tHU9hWBDyllOAfD0Q/S2M8sZx/lvTai/i6ojuUScnJ9fWdLqgeD0ZL3rM
Q8jfwuoH0d/MKIsXPUj76/HTp/wqqPua2NrothyKp5Yhndl+g/Jkt8MAUPS3M9aC7TfO83A2
1mZ7qHsj0q32JB7Fh1TWdPjsbFBN/qZWPoj+poZbvux27azvBrpGXJkkCdt9tdyteTcmxVMR
DDLIOyt4XW9v0YPob2/MFduT3f7D9QLkxwjrI93PpuhoosnCZR72OmHY4uXYLeeDvzsOkl1v
dLnDGXurA6/iL4nuv3h9vUDrI+cHy8585KFgTplEnnrtrmR4neSn0xbtU1OCL1S0BraaW17r
UPS3PPry3clL67xM9dLjzwR+4HYozwolcyri+7fpbM5keNEQqj/9T6o+6dz8JL95AED0Nz8F
FNsTGzxOdIoanhtzlPl+PELsfXl0P/Rm8w5Pw4shcjujyaOzhjke61siAKLHRDgh4FAbE+eb
Vg3bGN0T3y/G/UEPhRSKY/yeN5p3NNOezodDpDj/7qCKPBb2OQIgesyHGAIO1bZ3ftcrZ3vB
98GSCH8Gi445379NBkTwi0AvsTUyAKTivW8OhdDCVINVHUMARI8pkYiA5AszdS+jPMhlSxJ/
Cp+tJuV3JyTgxwsDBa8MNVLFr1egeKznRARA9JgYGQhQzLWxuldi03dFkM5ggqjMRMZ/7Xmz
PvE7K44maqiBiscSvo4AiP46RjiC1P3mAwXmGOpNVQbXXY6J8aew4xPjDycehUl2zPldesH7
3geoeKxOLQRA9Fow4SAVhuk8ij5FulWz4hb8w5+J8hfjeX/gTV417RpWHPbamw5mfTK/56F3
FedEfX8fybZGZajxAwJaCIDotWDCQeehORvnoTsY5eV7Zcp3F2TLn1lrzO/2vMGItPsyz8fQ
aYMcU8uAB2ogBobHgmQiAKJnAobDFQKUTb9xnu48am5hbF+OKH7ifPLfzvujgddq887dsOd5
s1FfeFZNQmcSPoNEw0fv7snZrOBsxfozQwBEb4YbzjryPRl0Vj+omZFWU9IUY87lfybaJ96X
xD/zJr0G23jeib2zWBZF7UcNvxiPpj9WVL8Aya1YcbkQANHngg8nn/H95ndRiMU0QjB7D/AD
Ifgl8Y9mA4+4f1gD+d+9DXvTqTcYSMVePLEfMKBIJZF99o1c4GB4LLFCEADRFwIjLnIg/O2a
FP7D94lBYRZttX86kNhfCH/aADpj2gJI/A/I7jOZTHq94fDtrcvN033tdt+Gw2Gv15tMPY/Y
nOh8Ph53BKO7QUF2mIzXpNyD/mzy/b8Fv29RgwyLqkAEQPQFgolLHRGgqL9/UAT+x65ZoRY+
56ed4Ye+7wdiRwhc2hTot6SYnyX95B+IvulHh9Bxxd2UeSVRDnTmdT8LLysiabCISkEARF8K
rLjoAQEqq0USf/t1SF7bXGH4TPJsweGyHJw3/EoGGvoOQqQk1kyZCIDoy0QX1z4hsFltRa+T
j/dUq0umgtanoGvcBMjHTNGkI693/5H0+3qLIvFYItUgAKKvBmfc5YSAs12tiPKdpy/DqUgP
LSLEvEbuvn5rWQWiP5sOv3wi48xqRWUlMB2AQLUIgOirxRt3O0dgQz5Hsko761/vVM1Ga4S+
yAQTFR8m+1/XZJohet+C3TH560MARF8f9rjzOQIiA0sU2HWefrsfTkSxAIpfbA3xqxRf0u2D
6fD+5YleQ0p3hM5gkjcDARB9M8YBTxFBQPoniSdJBTtPL/dk4zkSfzNs+xTJcyT2iSJ2Ynby
O68RNYOZ3EgEQPSNHBY8VBQBEXiomJ9E//bT51/uuxTrPhiISHcKdKd4SRHnXrB/l9hc1F8j
pa7ytESaVvf+l8+fKHCUeJ1cDdK/jLECAs1HAETf/DHCEyYhIIPO12QekTpaWH3ovzw/vnz4
8Z0Sn0Ta00SkPVHiE/1mlPw06o/6fcqAohwo+j/9K5E30TclWVGaFf0o00okWnW7r99/fHh5
eBYXpEuSQYl2GLHJgNUxE1uLAIi+tUOHB89EgES3JGr6kRlI7AbbldwXjv8ISa7+4rhP0CkA
FQhYiQCI3sphxUsBASAABN4RANFjNgABIAAELEcARG/5AOP1gAAQAAIgeswBIAAEgIDlCIDo
LR9gvB4QAAJAAESPOQAEgAAQsBwBEL3lA4zXAwJAAAiA6DEHgAAQAAKWIwCit3yA8XpAAAgA
ARA95gAQAAJAwHIEQPSWDzBeDwgAASAAosccAAJAAAhYjgCI3vIBxusBASAABED0mANAAAgA
AcsRANFbPsB4PSAABIAAiB5zAAgAASBgOQIgessHGK8HBIAAEADRYw4AASAABCxHAERv+QDj
9YAAEAACIHrMASAABICA5QiA6C0fYLweEAACQABEjzkABIAAELAcARC95QOM1wMCQAAIgOgx
B4AAEAACliMAord8gPF6QAAIAAEQPeYAEAACQMByBED0lg8wXg8IAAEgAKLHHAACQAAIWI4A
iN7yAcbrAQEgAARA9JgDQAAIAAHLEQDRWz7AeD0gAASAAIgecwAIAAEgYDkCIHrLBxivBwSA
ABAA0WMOAAEgAAQsRwBEb/kA4/WAABAAAiB6zAEgAASAgOUIgOgtH2C8HhAAAkAARI85AASA
ABCwHAEQveUDjNcDAkAACIDoMQeAABAAApYjAKK3fIDxekAACAABED3mABAAAkDAcgRA9JYP
MF4PCAABIACixxwAAkAACFiOAIje8gHG6wEBIAAEQPSYA0AACAAByxEA0Vs+wHg9IAAEgACI
HnMACAABIGA5AiB6ywcYrwcEgAAQANFjDgABIAAELEcARG/5AOP1gAAQAAIgeswBIAAEgIDl
CIDoLR9gvB4QAAJAAESPOQAEgAAQsBwBEL3lA4zXAwJAAAiA6DEHgAAQAAKWIwCit3yA8XpA
AAgAARA95gAQAAJAwHIEQPSWDzBeDwgAASAAosccAAJAAAhYjgCI3vIBxusBASAABED0mANA
AAgAAcsRANFbPsB4PSAABIAAiB5zAAgAASBgOQIgessHGK8HBIAAEPh/nbnmspASo2YAAAAA
SUVORK5CYIK3AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brO
EYyCAKoAS6kLRgAAAG0AYQBpAGwAdABvADoAZABlAHIAcgBpAGUAcgBlAEAAbgBlAHcAYgA2
AC4AdQAtAHMAdAByAGEAcwBiAGcALgBmAHIAAACtAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyC
AKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLPAAAAG0AYQBpAGwAdABvADoAbgBvAHIA
bQBhAG4AQABhAHMAdAByAG8ALgBnAGwAYQAuAGEAYwAuAHUAawAAAJsAAABEAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQsqAAAAbQBhAGkAbAB0
AG8AOgByAGcAbQBAAHIAbwBlAC4AYQBjAC4AdQBrAAAAqwAAAEQAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6
zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupCzoAAABtAGEAaQBsAHQAbwA6AGEA
bgBkAHIAZQBhAEAAcgBtAC4AaQBhAHMAZgAuAGMAbgByAC4AaQB0AAAApwAAAEQAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA0Mnqefm6zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupCzYAAABtAGEAaQBs
AHQAbwA6AGoAYwBtAEAAYwBmAGEALgBoAGEAcgB2AGEAcgBkAC4AZQBkAHUAAAC3AAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLRgAAAG0A
YQBpAGwAdABvADoAZgByAGEAbgBjAG8AaQBzAEAAdgBpAHoAaQByAC4AdQAtAHMAdAByAGEA
cwBiAGcALgBmAHIAAACnAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADg
yep5+brOEYyCAKoAS6kLNgAAAG0AYQBpAGwAdABvADoAUABlAGQAcgBvAC4ATwBzAHUAbgBh
AEAAZQBzAGEALgBpAG4AdAAAAKMAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAA
AwAAAODJ6nn5us4RjIIAqgBLqQsyAAAAbQBhAGkAbAB0AG8AOgBnAHQAcgBAAGEAcwB0AC4A
YwBhAG0ALgBhAGMALgB1AGsAAACpAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAA
AAMAAADgyep5+brOEYyCAKoAS6kLOAAAAG0AYQBpAGwAdABvADoAcgBvAHkAQABjAGEAYwBy
AC4AYwBhAGwAdABlAGMAaAAuAGUAZAB1AAAArwAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCq
AEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupCz4AAABoAHQAdABwADoALwAvAHcAdwB3AC4A
aQB2AG8AYQAuAG4AZQB0AC8ARABvAGMAdQBtAGUAbgB0AHMALwAAAGQAFiQBFyQBSWYBAAAA
AZZt/yF2AAJoATXWBQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzW
AwABATXWBQABA2MDNdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2
AAJoATXWBQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXW
BQABA2MDNdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2AAJoATXW
BQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXWBQABA2MD
NdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2AAJoATXWBQABA2MD
NdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXWBQABA2MDNdYFAQID
dCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2AAJoATXWBQABA2MDNdYFAQID
dCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXWBQABA2MDNdYFAQIDdCA01gYA
AQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2AAJoATXWBQABA2MDNdYFAQIDdCAjdgAB
YwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXWBQABA2MDNdYFAQIDdCA01gYAAQ8AAABh
9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2AAJoATXWBQABA2MDNdYFAQIDdCAjdgABYwMjdgEC
dCA6VgsAFPYD1yMY9gMAACzWAwABATXWBQABA2MDNdYFAQIDdCA01gYAAQ8AAABh9gNt/2QA
FiQBFyQBSWYBAAAAAZZt/yF2AAJoATXWBQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsA
FPYD1yMY9gMAACzWAwABATXWBQABA2MDNdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQB
SWYBAAAAAZZt/yF2AAJoATXWBQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY
9gMAACzWAwABATXWBQABA2MDNdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAA
AZZt/yF2AAJoATXWBQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzW
AwABATXWBQABA2MDNdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2
AAJoATXWBQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXW
BQABA2MDNdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2AAJoATXW
BQABA2MDNdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXWBQABA2MD
NdYFAQIDdCA01gYAAQ8AAABh9gNt/2QAFiQBFyQBSWYBAAAAAZZt/yF2AAJoATXWBQABA2MD
NdYFAQIDdCAjdgABYwMjdgECdCA6VgsAFPYD1yMY9gMAACzWAwABATXWBQABA2MDNdYFAQID
dCA01gYAAQ8AAABh9gNt/6MAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAA
AAMDAAAAAAAAwAAAAAAAAEYAABQAAABDOlxob21lXFVDRFxVQ0RcanNcAP//rd4AAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAADYAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAsA
AAADAwAAAAAAAMAAAAAAAABGAAA1AAAAQzpcaG9tZVxzZWJcRG9jdW1lbnRzXFVDRFxEb2N1
bWVudHNcVUNELTIwMDMwOTIyLmRvYwD//63eAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAA
AFUAQwBEAHQAcgBlAGUAAABkABYkARckAUlmAQAAAAGWbf8hdgACaAE11gUAAQPyAjXWBQEC
A+UgI3YAAfICI3YBAuUgOlYLABT2A9cjGPYDAAAs1gMAAQE11gUAAQPyAjXWBQECA+UgNNYG
AAEPAAAAYfYDbf9kABYkARckAUlmAQAAAAGWbf8hdgACaAE11gUAAQPyAjXWBQECA+UgI3YA
AfICI3YBAuUgOlYLABT2A9cjGPYDAAAs1gMAAQE11gUAAQPyAjXWBQECA+UgNNYGAAEPAAAA
YfYDbf9kABYkARckAUlmAQAAAAGWbf8hdgACaAE11gUAAQPyAjXWBQECA+UgI3YAAfICI3YB
AuUgOlYLABT2A9cjGPYDAAAs1gMAAQE11gUAAQPyAjXWBQECA+UgNNYGAAEPAAAAYfYDbf9k
ABYkARckAUlmAQAAAAGWbf8hdgACaAE11gUAAQPyAjXWBQECA+UgI3YAAfICI3YBAuUgOlYL
ABT2A9cjGPYDAAAs1gMAAQE11gUAAQPyAjXWBQECA+UgNNYGAAEPAAAAYfYDbf9kABYkARck
AUlmAQAAAAGWbf8hdgACaAE11gUAAQPyAjXWBQECA+UgI3YAAfICI3YBAuUgOlYLABT2A9cj
GPYDAAAs1gMAAQE11gUAAQPyAjXWBQECA+UgNNYGAAEPAAAAYfYDbf9kABYkARckAUlmAQAA
AAGWbf8hdgACaAE11gUAAQPyAjXWBQECA+UgI3YAAfICI3YBAuUgOlYLABT2A9cjGPYDAAAs
1gMAAQE11gUAAQPyAjXWBQECA+UgNNYGAAEPAAAAYfYDbf9kABYkARckAUlmAQAAAAGWbf8h
dgACaAE11gUAAQMXBDXWBQECA8AfI3YAARcEI3YBAsAfOlYLABT2A9cjGPYDAAAs1gMAAQE1
1gUAAQMXBDXWBQECA8AfNNYGAAEPAAAAYfYDbf9kABYkARckAUlmAQAAAAGWbf8hdgACaAE1
1gUAAQMXBDXWBQECA8AfI3YAARcEI3YBAsAfOlYLABT2A9cjGPYDAAAs1gMAAQE11gUAAQMX
BDXWBQECA8AfNNYGAAEPAAAAYfYDbf9kABYkARckAUlmAQAAAAGWbf8hdgACaAE11gUAAQMX
BDXWBQECA8AfI3YAARcEI3YBAsAfOlYLABT2A9cjGPYDAAAs1gMAAQE11gUAAQMXBDXWBQEC
A8AfNNYGAAEPAAAAYfYDbf9kABYkARckAUlmAQAAAAGWbf8hdgACaAE11gUAAQMXBDXWBQEC
A8AfI3YAARcEI3YBAsAfOlYLABT2A9cjGPYDAAAs1gMAAQE11gUAAQMXBDXWBQECA8AfNNYG
AAEPAAAAYfYDbf9kABYkARckAUlmAQAAAAGWbf8hdgACaAE11gUAAQMXBDXWBQECA8AfI3YA
ARcEI3YBAsAfOlYLABT2A9cjGPYDAAAs1gMAAQE11gUAAQMXBDXWBQECA8AfNNYGAAEPAAAA
YfYDbf9FCAAARABkAAAAAAAAAAgAAAAAAAAAAAAAAAAAihv3CNUD2wMAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBOAAAAsgQK8AgAAAACBAAAAAoAAEMAC/AqAAAABEEC
AAAABcESAAAABgECAAAA/wEAAAgAcwBwAGUAYwB0AHIAdQBtAAAAAAAQ8AQAAAABAACAYgAH
8KMHAAAGBlTFXDVOCWOzGHkpME+vwDf/AH8HAAABAAAAZy8CAAAAagMAbh7wdwcAAFTFXDVO
CWOzGHkpME+vwDf/iVBORw0KGgoAAAANSUhEUgAAAdYAAACZBAMAAABgTQZkAAAAGFBMVEUA
AACPAI////8AAI8AAP8AAAAAAAAAAAAT9b43AAAAAWJLR0QAiAUdSAAAAAxjbVBQSkNtcDA3
MTIAAAAHT223pQAABuRJREFUeNrtnQtyozgQhrXMBTaeCwDJATKqOYHX9z/TAuIhQP3Ug0fc
lVIRR5b0of5bwlZXTPtzzBw9gDdrJlZTHdV16Y7frG/WN6u+67wWZN3bt1fGW6p2zsP666Ks
Gvslf0tp8fz42GS9Mt6gdq7L+nlRVo19it9xAKvK6jGmXWO02LutV+KsFaMLy6jDHS2nvxys
1apvuV7PwUqbhDWesOumNl2XddyanIw1n9V9XOiLKger9UqMtWbdKcuphA2xY3Q/x+l1HYez
6bWjHHD7i8P0ymWNtN55Btb2QNaqjF4zs1qvjGe1jDrXYs2p15yxiTOAcuurmdacPkacgjWf
1W4v0XMesr5KLEk741Kefl41rJn3w7xti4JVYxn3w6djzWzZWK1XAtZ8PLhdWG5F1Bp2f6lZ
m4/OVq9k1mvXYTSszjW6WW3aNWxmvXYdRsOqWPtuO59KcKvZPT76XnOwWq8EUMfeObCWUYdC
/VjKoqyOcIgVzeLHWfU63tNIP5L78DSZY/cTbE69zhMaBytmnf127L+EaGfnifNiqQ8vEv2Y
XyEGYNtI8+5mFKyQ1YtGzTKWfgD59Lrio26smBXp9rFcL5e9H+fT65ouQjIi1tUa42/a4td5
BPWB/x7Jar0SQl1vUDHR2jbGdgrVS1bAup289W+/wSHEse6nUQ3L9+Gdn272/nkWn9DjjbYj
Nuteknvnit2whnoNvaqE5fpwIPo0u/eFYW2rtzCVMhQyWUOtr93r08E+oNZUBj2g6yTL8+Hg
jQywJl58YCQVLIs1TBC86UlFi9w4zT3l+DA0WeFXd7C2VRo6eQpYBivol8BnMFvRqllRD1F4
Me3DsAShz5sS+TExc3JYkhWJNg34phSwJIu4E8qHscCKfGTr+7HVsdIkUskSrOgasmLdPNN5
b9SxckCEsLgP48slxhorWpYahZJFWamdAf7XKFjelMlgMR8mN0FET6NorQKV++2NyIsR1j9k
Qz5r6DMY58cKVv58SWAN+GXfZlbrwNf3/qLjsXo1UT+GDwQgBJsjE6DvBRoHWbeNBFnD/fg1
sSd4kBXz4O3xEMgFuKx2QLUpWLuGbAsYxIp68O4oDFCbz9rPqow17MN9pT/Q0CFWVIP7Yz/h
6mHWw/Jz8lpG1tMZk/XbK+MtVTspWEN6XUpMr76BeoXXV9UhNO4xPcmaszU9q2Q412BVMJyC
1XplPKtl1svPGqoXYqWsSH5OnF3lPGIGVj9nATsgrKknOVRYV1PLAow6vNRQrJXrCRzcph7J
WklZ57vIZK0mVqSLAGvV2okB7Mw/F+4uPsl6BVjxLoKsEwP8xjystZmyNdz8UKybRLsoVriv
PStdj2YdnH3wQxZr77N+op2K9duMPSPdLHI2SEhY590RrIO4h5+K5cPbZBaXwyNineOrwefV
q2cwH2bH4WGWhjBhOKy7RDtlHJ4YWKwVrlc+azX7AY91k5ClYK1UsYmsN0xAZlaFXjVrzuVZ
0b1EJVtzGKyy2FSHYpNmzZlucAX1s6pHszrhomN3y8egb16qoJnWHO8G6VnBJ6g9K12vJh/H
jMuZc+lzNGu9SrQTszqzXhlvwnYcYF0xqzu4hrP7PN/zq/AJfpzIh5ZVY8meX3WsnC+7zpdP
V5jVemW8pWoHNc4XtufTa2FWjR39eVNJ1qONIdi76LUo69GfDzd0ldvolRGcbqNXLav1ynhL
1Q5htGBvo1ctq8aO1isjON1GrwzB3kevBVkP1yu9S7yPXungdB+9KlmtV8ZbqnYoIwV7I73q
WDV2vF7J4HQjvZKCRXw4laVtLQur0CmP1yu5S7yTXqngdCe9qlhtXySbKFsMlhDsnfSqYtXY
CfRKBac76ZUS7K30Wor1DHoldolB1tdzKgSsL+APXy9RO3qrTRecxGcINKxfF2X922P+l4r1
bznW5iFnfXUmZP18QVaO1fzzr+CstDM3xlSs5XzYmDKsX6dg/ZCzPttrxibFWa436z1Zb2pv
1nvaD2btAsm8JPbBSRigWve+L/nyrB/8nNHgHx+eDjWuDjcCrE/HqoqhI2uB8LvOotOwPpdF
RzU5PWuZpWY9nXGsuvHmZoWy6MaL4dX+QPyS4TElEmGsOs1lZgWz6MYLl+tQLYkSY84EwOrG
qZWcY80Wm8AsulG441/GGmbJv0DjsDKW5o3DcBbdxNqOrGON7rLisKr1mpMVyqJb9Gr8Gs6T
AdbnqWMTnFm21evMWnNYz7jmUKz14sMTq4F92GNV7yVyskJZdDOr8WKTY61R1ikgP8/GCmXR
TRe1t+ZMrIQPTxeKEedfX0NZdMvFwjrmtQJ6vYrR/64u8AHFtVllNd6sp7efxKqy/wET4XOQ
cwnT8QAAAABJRU5ErkJgguQAFiQBFyQBSWYBAAAAAZb7/yF2AAVoATXWBQABA5ILNdYFAQID
KQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcjdgABkgsjdgECKQUjdgIDDAYjdgMElAQjdgQF
5gc6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAA
AAD/AAAAABT2AQAAF/YAAAA11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQF
A+YHL9YLAAUEAAAA/wQBAAA01gYAAQ8AAACKVAEAjAAWJAEXJAFJZgEAAAABlvv/IXYAAWgB
NdYFAAEDQSMjdgABQSM6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAF/YAAAA11gUAAQNBIy/WCwABBQAAAP8EAQAANNYG
AAEPAAAAilQBAOQAFiQBFyQBSWYBAAAAAZb7/yF2AAVoATXWBQABA5ILNdYFAQIDKQU11gUC
AwMMBjXWBQMEA5QENdYFBAUD5gcjdgABkgsjdgECKQUjdgIDDAYjdgMElAQjdgQF5gc6VgsA
B5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAA
ABT2AQAAF/YAAAA11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHL9YL
AAUBAAAA/wQBAAA01gYAAQ8AAACKVAEA1gAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAED
kgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2
AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA
AAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAADXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQME
A5QENdYFBAUD5gc01gYAAQ8AAACKVAEA1gAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAED
kgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2
AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA
AAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAADXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQME
A5QENdYFBAUD5gc01gYAAQ8AAACKVAEA1gAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAED
kgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2
AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA
AAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAADXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQME
A5QENdYFBAUD5gc01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAED
kgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2
AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA
AAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMM
BjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/IXYABWgB
NdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2
AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA
/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU1
1gUCAwMMBjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/
IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2
AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYF
AQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEA
AAABlvv/IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2
AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQAB
A5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEA3AAWJAEX
JAFJZgEAAAABlvv/IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUE
BQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAA
AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwAB
ATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEA
3AAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQD
lAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA
/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAA
ACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gc01gYAAQ8A
AACKVAEA3AAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwG
NdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+
E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYB
AAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gc0
1gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAEDkgs11gUBAgMpBTXW
BQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpW
CwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8A
AAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYF
BAUD5gc01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAEDkgs11gUB
AgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2
BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAA
AAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQME
A5QENdYFBAUD5gc01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAED
kgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2
AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA
AAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMM
BjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/IXYABWgB
NdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2
AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA
/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU1
1gUCAwMMBjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEA6gAWJAEXJAFJZgEAAAABlvv/
IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2
AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYF
AQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcv1gsABQQAAAD/BAEAADTWBgABDwAAAIpU
AQCSABYkARckAUlmAQAAAAGW+/8hdgABaAE11gUAAQNBIyN2AAFBIzpWCwAHlLX+E9YwAAAA
/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAA
ACzWAwABATXWBQABA0EjL9YLAAEFAAAA/wQBAAA01gYAAQ8AAACKVAEA6gAWJAEXJAFJZgEA
AAABlvv/IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2
AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQAB
A5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcv1gsABQEAAAD/BAEAADTWBgAB
DwAAAIpUAQDcABYkARckAUlmAQAAAAGW+/8hdgAFaAE11gUAAQOSCzXWBQECAykFNdYFAgMD
DAY11gUDBAOUBDXWBQQFA+YHI3YAAZILI3YBAikFI3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeU
tf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU
9gEAABf2AAAALNYDAAEBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPm
BzTWBgABDwAAAIpUAQDcABYkARckAUlmAQAAAAGW+/8hdgAFaAE11gUAAQOSCzXWBQECAykF
NdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHI3YAAZILI3YBAikFI3YCAwwGI3YDBJQEI3YEBeYH
OlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA
/wAAAAAU9gEAABf2AAAALNYDAAEBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ1
1gUEBQPmBzTWBgABDwAAAIpUAQDcABYkARckAUlmAQAAAAGW+/8hdgAFaAE11gUAAQOSCzXW
BQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHI3YAAZILI3YBAikFI3YCAwwGI3YDBJQE
I3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8A
AAAAAAAA/wAAAAAU9gEAABf2AAAALNYDAAEBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYF
AwQDlAQ11gUEBQPmBzTWBgABDwAAAIpUAQDcABYkARckAUlmAQAAAAGW+/8hdgAFaAE11gUA
AQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHI3YAAZILI3YBAikFI3YCAwwG
I3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA
AAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2AAAALNYDAAEBNdYFAAEDkgs11gUBAgMpBTXWBQID
AwwGNdYFAwQDlAQ11gUEBQPmBzTWBgABDwAAAIpUAQDcABYkARckAUlmAQAAAAGW+/8hdgAF
aAE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHI3YAAZILI3YBAikF
I3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA
AAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2AAAALNYDAAEBNdYFAAEDkgs11gUBAgMp
BTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmBzTWBgABDwAAAIpUAQDcABYkARckAUlmAQAAAAGW
+/8hdgAFaAE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHI3YAAZIL
I3YBAikFI3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA
/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2AAAALNYDAAEBNdYFAAEDkgs1
1gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmBzTWBgABDwAAAIpUAQDcABYkARckAUlm
AQAAAAGW+/8hdgAFaAE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YH
I3YAAZILI3YBAikFI3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8E
AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2AAAALNYDAAEBNdYF
AAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmBzTWBgABDwAAAIpUAQDqABYk
ARckAUlmAQAAAAGW+/8hdgAFaAE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXW
BQQFA+YHI3YAAZILI3YBAikFI3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEA
AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2AAAALNYD
AAEBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmBy/WCwAFBAAAAP8E
AQAANNYGAAEPAAAAilQBAJIAFiQBFyQBSWYBAAAAAZb7/yF2AAFoATXWBQABA0EjI3YAAUEj
OlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA
/wAAAAAU9gEAABf2AAAALNYDAAEBNdYFAAEDQSMv1gsAAQUAAAD/BAEAADTWBgABDwAAAIpU
AQDqABYkARckAUlmAQAAAAGW+/8hdgAFaAE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUD
BAOUBDXWBQQFA+YHI3YAAZILI3YBAikFI3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAA
AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2
AAAALNYDAAEBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmBy/WCwAF
AQAAAP8EAQAANNYGAAEPAAAAilQBANwAFiQBFyQBSWYBAAAAAZb7/yF2AAVoATXWBQABA5IL
NdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcjdgABkgsjdgECKQUjdgIDDAYjdgME
lAQjdgQF5gc6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA
/wAAAAAAAAD/AAAAABT2AQAAF/YAAAAs1gMAAQE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY1
1gUDBAOUBDXWBQQFA+YHNNYGAAEPAAAAilQBANwAFiQBFyQBSWYBAAAAAZb7/yF2AAVoATXW
BQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcjdgABkgsjdgECKQUjdgID
DAYjdgMElAQjdgQF5gc6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAF/YAAAAs1gMAAQE11gUAAQOSCzXWBQECAykFNdYF
AgMDDAY11gUDBAOUBDXWBQQFA+YHNNYGAAEPAAAAilQBANwAFiQBFyQBSWYBAAAAAZb7/yF2
AAVoATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcjdgABkgsjdgEC
KQUjdgIDDAYjdgMElAQjdgQF5gc6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA
AAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAF/YAAAAs1gMAAQE11gUAAQOSCzXWBQEC
AykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHNNYGAAEPAAAAilQBAOoAFiQBFyQBSWYBAAAA
AZb7/yF2AAVoATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcjdgAB
kgsjdgECKQUjdgIDDAYjdgMElAQjdgQF5gc6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAA
AAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAF/YAAAAs1gMAAQE11gUAAQOS
CzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHL9YLAAUEAAAA/wQBAAA01gYAAQ8A
AACKVAEAkgAWJAEXJAFJZgEAAAABlvv/IXYAAWgBNdYFAAEDQSMjdgABQSM6VgsAB5S1/hPW
MAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAA
F/YAAAAs1gMAAQE11gUAAQNBIy/WCwABBQAAAP8EAQAANNYGAAEPAAAAilQBAOoAFiQBFyQB
SWYBAAAAAZb7/yF2AAVoATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD
5gcjdgABkgsjdgECKQUjdgIDDAYjdgMElAQjdgQF5gc6VgsAB5S1/hPWMAAAAP8EAQAAAAAA
/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAF/YAAAAs1gMAAQE1
1gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHL9YLAAUBAAAA/wQBAAA0
1gYAAQ8AAACKVAEA6gAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAEDkgs11gUBAgMpBTXW
BQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpW
CwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8A
AAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQMEA5QENdYF
BAUD5gcv1gsABQQAAAD/BAEAADTWBgABDwAAAIpUAQCSABYkARckAUlmAQAAAAGW+/8hdgAB
aAE11gUAAQNBIyN2AAFBIzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA
/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA0EjL9YLAAEFAAAA
/wQBAAA01gYAAQ8AAACKVAEA6gAWJAEXJAFJZgEAAAABlvv/IXYABWgBNdYFAAEDkgs11gUB
AgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2AQIpBSN2AgMMBiN2AwSUBCN2
BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/AAAA
AAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYFAQIDKQU11gUCAwMMBjXWBQME
A5QENdYFBAUD5gcv1gsABQEAAAD/BAEAADTWBgABDwAAAIpUAQDqABYkARckAUlmAQAAAAGW
+/8hdgAFaAE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YHI3YAAZIL
I3YBAikFI3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8EAQAAAAAA
/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2AAAALNYDAAEBNdYFAAEDkgs1
1gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmBy/WCwAFBAAAAP8EAQAANNYGAAEPAAAA
ilQBAJIAFiQBFyQBSWYBAAAAAZb7/yF2AAFoATXWBQABA0EjI3YAAUEjOlYLAAeUtf4T1jAA
AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2
AAAALNYDAAEBNdYFAAEDQSMv1gsAAQUAAAD/BAEAADTWBgABDwAAAIpUAQDqABYkARckAUlm
AQAAAAGW+/8hdgAFaAE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQFA+YH
I3YAAZILI3YBAikFI3YCAwwGI3YDBJQEI3YEBeYHOlYLAAeUtf4T1jAAAAD/BAEAAAAAAP8E
AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8AAAAAAAAA/wAAAAAU9gEAABf2AAAALNYDAAEBNdYF
AAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmBy/WCwAFAQAAAP8EAQAANNYG
AAEPAAAAilQBAOoAFiQBFyQBSWYBAAAAAZb7/yF2AAVoATXWBQABA5ILNdYFAQIDKQU11gUC
AwMMBjXWBQMEA5QENdYFBAUD5gcjdgABkgsjdgECKQUjdgIDDAYjdgMElAQjdgQF5gc6VgsA
B5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAAAAD/AAAA
ABT2AQAAF/YAAAAs1gMAAQE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOUBDXWBQQF
A+YHL9YLAAUEAAAA/wQBAAA01gYAAQ8AAACKVAEAkgAWJAEXJAFJZgEAAAABlvv/IXYAAWgB
NdYFAAEDQSMjdgABQSM6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wAAAAAAAAD/AAAAABT2AQAAF/YAAAAs1gMAAQE11gUAAQNBIy/WCwABBQAAAP8E
AQAANNYGAAEPAAAAilQBAOoAFiQBFyQBSWYBAAAAAZb7/yF2AAVoATXWBQABA5ILNdYFAQID
KQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gcjdgABkgsjdgECKQUjdgIDDAYjdgMElAQjdgQF
5gc6VgsAB5S1/hPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wAAAAAA
AAD/AAAAABT2AQAAF/YAAAAs1gMAAQE11gUAAQOSCzXWBQECAykFNdYFAgMDDAY11gUDBAOU
BDXWBQQFA+YHL9YLAAUBAAAA/wQBAAA01gYAAQ8AAACKVAEA3AAWJAEXJAFJZgEAAAABlvv/
IXYABWgBNdYFAAEDkgs11gUBAgMpBTXWBQIDAwwGNdYFAwQDlAQ11gUEBQPmByN2AAGSCyN2
AQIpBSN2AgMMBiN2AwSUBCN2BAXmBzpWCwAHlLX+E9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E
AQAAAAAA/wQBAAAAAAD/AAAAAAAAAP8AAAAAFPYBAAAX9gAAACzWAwABATXWBQABA5ILNdYF
AQIDKQU11gUCAwMMBjXWBQMEA5QENdYFBAUD5gc01gYAAQ8AAACKVAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAUACwAEgABAJwADwADAAAAAAAAAAAAZAAAQPH/AgBkAAwAAAAAAAAA
AAAGAE4AbwByAG0AYQBsAAAAHgAAABOkZAAUpGQAMSQBDcYCAAAqJAE3JAE1JAEzJAEfAEIq
AE9KAABRSgAAQ0oYAG1ICQRzSAkEUEoAAENKGAAAVgABQAEAAgBWAAwAAACVJq0AAAAJAEgA
ZQBhAGQAaQBuAGcAIAAxAAAADwABAAYkAQomAAtGDwBAJgAAGQBCKgpPSgIAUUoCAENKIAA1
CAFDSiAANQgBAFYAAkABAAIAVgAMAAAAlSatAAAACQBIAGUAYQBkAGkAbgBnACAAMgAAAA8A
AgAGJAEKJgELRg8AQCYBABkAQioKT0oCAFFKAgBDShwANQgBQ0ocADUIAQBcAANAAQACAFwA
DAAoAJUmrQAAAAkASABlAGEAZABpAG4AZwAgADMAAAAXAAMABiQBCiYCC0YPAA3GBQABaAEA
QCYCABgANQiBQioKT0oCAFFKAgBhShgAcGgAgIAAUAAEQAEAAgBQAAwAAAAAAAAAAAAJAEgA
ZQBhAGQAaQBuAGcAIAA0AAAAFgAEAAMkAQYkAQ3GBQAB0AIGQCYDYSQBDgBDShYANQgBQ0oW
ADUIAVYABUABAAIAVgAMAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAANQAAABUABQANxgUA
AdACBhOk8AAUpDwAQCYEABQAQ0oaADYIATUIAUNKGgA2CAE1CAFQAAZAAQACAFAADAAAAAAA
AAAAAAkASABlAGEAZABpAG4AZwAgADYAAAAVAAYADcYFAAHQAgYTpPAAFKQ8AEAmBQAOAENK
FgA1CAFDShYANQgBQgAHQAEAAgBCAAwAAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAA3AAAA
FQAHAA3GBQAB0AIGE6TwABSkPABAJgYAAABIAAhAAQACAEgADAAAAAAAAAAAAAkASABlAGEA
ZABpAG4AZwAgADgAAAAVAAgADcYFAAHQAgYTpPAAFKQ8AEAmBwAGADYIATYIAVIACUABAAIA
UgAMAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAAOQAAABUACQANxgUAAdACBhOk8AAUpDwA
QCYIABAAT0oCAFFKAgBDShYAQ0oWAEQAQUDy/6EARAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUA
bAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGlA8/+zAFYADAEAAAAA
AAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgABBQMAADTW
BgABCgNsAGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQA
AAACAAwAAAAAADQAIEABAPIANAAMAAAAymBzAAAABgBGAG8AbwB0AGUAcgAAAA0ADwANxggA
AuAQwCEBAgAAAC4AKUCiAAEBLgAMAAAAymBzAAAACwBQAGEAZwBlACAATgB1AG0AYgBlAHIA
AAAAADQAH0ABABIBNAAMAAAAQl1sAAAABgBIAGUAYQBkAGUAcgAAAA0AEQANxggAAuAQwCEB
AgAAAEAAVkCiACEBQAAMAAAAC0G1AAAAEQBGAG8AbABsAG8AdwBlAGQASAB5AHAAZQByAGwA
aQBuAGsAAAAGAD4qAUIqDGIA/k+iADEBYgAMAAAAxBBwAAAAGQBTAHQAeQBsAGUAIABMAHUA
YwBpAGQAYQAgAEMAbwBuAHMAbwBsAGUAIAA5ACAAcAB0AAAAGAA1CIFCKgZDShIAT0oDAFFK
AwBwaP9mAAAoAFdAogBBASgADAAAAAtBtQAAAAYAUwB0AHIAbwBuAGcAAAADADUIAQCkAP5P
AQBSAaQADAAAAMQQcAAAADQAUwB0AHkAbABlACAATAB1AGMAaQBkAGEAIABDAG8AbgBzAG8A
bABlACAAOQAgAHAAdAAgAEIAZQBmAG8AcgBlADoAIAAgADQAIABwAHQAIABBAGYAdABlAHIA
OgAgACAANAAgAHAAdAAAAAoAFQATpFAAFKRQABgANQiBQioGQ0oSAE9KAwBRSgMAcGj/ZgAA
pAD+TwEAYgGkAAwAAADEEHAAAAA0AFMAdAB5AGwAZQAgAEwAdQBjAGkAZABhACAAQwBvAG4A
cwBvAGwAZQAgADkAIABwAHQAIABCAGUAZgBvAHIAZQA6ACAAIAAwACAAcAB0ACAAQQBmAHQA
ZQByADoAIAAgADAAIABwAHQAAAAKABYAE6QAABSkAAAYADUIgUIqBkNKEgBPSgMAUUoDAHBo
/2YAADwAIkABAAIAPAAMAQAAbmb5AAAABwBDAGEAcAB0AGkAbwBuAAAACgAXABOkeAAUpHgA
CgA1CIFDShQAXAiBQAD+TwEAggFAAAwAAABuZvkAAAAOAFMAdAB5AGwAZQAgAE4AdQBtAGIA
ZQByAGUAZAAAAAkAGAAKJgALRh0AAAAAQgD+TwEAkgFCAAwAAAC7Rc0AAAAHAGIAdQBsAGwA
ZQB0ADMAAAAZABkACiYAC0YXAA+E0AIRhAAAXoTQAmCEAAAAAABYAP5PAQCiAVgADAAAALtF
zQAAAB4AUwB0AHkAbABlACAAQgB1AGwAbABlAHQAZQBkACAAUwB5AG0AYgBvAGwAIAAoAHMA
eQBtAGIAbwBsACkAAAACABoAAAA+AEJAAQCyAT4ADAAAAAAAAAAAAAkAQgBvAGQAeQAgAFQA
ZQB4AHQAAAACABsAEABPSgIAUUoCAENKFgBDShYAPgAdQAEAwgE+AAwBAAAAAAAAAAANAEYA
bwBvAHQAbgBvAHQAZQAgAFQAZQB4AHQAAAACABwACABDShQAQ0oUAD4AE0ABAAIAPgAMAQAA
AAAAAAAABQBUAE8AQwAgADEAAAASAB0AE6Q8ABSkPAANxgUAAbYhCggAQ0oUAENKFABGABRA
AQACAEYADAEAAAAAAAAAAAUAVABPAEMAIAAyAAAAGgAeAA6EAAAPhPAAEYQBAF2EAABehPAA
YIQBAAgAQ0oUAENKFAA+ABVAAQACAD4ADAEAAAAAAAAAAAUAVABPAEMAIAAzAAAAGgAfAA6E
AAAPhOABEYQBAF2EAABehOABYIQBAAAAPgAWQAEAAgA+AAwBAAAAAAAAAAAFAFQATwBDACAA
NAAAABoAIAAOhAAAD4TQAhGEAQBdhAAAXoTQAmCEAQAAAD4AF0ABAAIAPgAMAQAAAAAAAAAA
BQBUAE8AQwAgADUAAAAaACEADoQAAA+EwAMRhAEAXYQAAF6EwANghAEAAAA+ABhAAQACAD4A
DAEAAAAAAAAAAAUAVABPAEMAIAA2AAAAGgAiAA6EAAAPhLAEEYQBAF2EAABehLAEYIQBAAAA
PgAZQAEAAgA+AAwBAAAAAAAAAAAFAFQATwBDACAANwAAABoAIwAOhAAAD4SgBRGEAQBdhAAA
XoSgBWCEAQAAAD4AGkABAAIAPgAMAQAAAAAAAAAABQBUAE8AQwAgADgAAAAaACQADoQAAA+E
kAYRhAEAXYQAAF6EkAZghAEAAAA+ABtAAQACAD4ADAEAAAAAAAAAAAUAVABPAEMAIAA5AAAA
GgAlAA6EAAAPhIAHEYQBAF2EAABehIAHYIQBAAAAQAA+QAEAAgBAAAwAAAAAAAAAAAAFAFQA
aQB0AGwAZQAAAAIAJgAZAEIqCk9KAgBRSgIAQ0ooADUIAUNKKAA1CAEASACZQAEAcgJIAAwB
AADMSQkAAAAMAEIAYQBsAGwAbwBvAG4AIABUAGUAeAB0AAAAAgAnABQAQ0oQAE9KBQBRSgUA
XkoFAGFKEABcAP5PogCBAlwADAADAKo/BQAAAA4ASABlAGEAZABpAG4AZwAgADMAIABDAGgA
YQByAAAAKAA1CAFCKgpDShgAT0oCAFFKAgBfSAEEYUoYAG1ICQRwaACAgABzSAkEQAAmQKIA
kQJAAAwBAAANKlgAAAASAEYAbwBvAHQAbgBvAHQAZQAgAFIAZQBmAGUAcgBlAG4AYwBlAAAA
AwBIKgEAdABdQAEAAgB0AA4AAADLaW0AAAAQAHoALQBCAG8AdAB0AG8AbQAgAG8AZgAgAEYA
bwByAG0AAAAhACoAAyQBE6QAABSkAAAkZAYBAAFOxggAAAD/BgEBAGEkAQAXADwIgUNKEABP
SgIAUUoCAF5KAgBhShAAAG4AXEABAAIAbgAOAAAAy2ltAAAADQB6AC0AVABvAHAAIABvAGYA
IABGAG8AcgBtAAAAIQArAAMkAROkAAAUpAAAJmQGAQABUMYIAAAA/wYBAQBhJAEAFwA8CIFD
ShAAT0oCAFFKAgBeSgIAYUoQAAAAAAAAAQAAAITaAAD/////AAAAAAEA/////wAAAAAAAAAA
AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABAAAAAAAAAAACP//AAAAAAAAAABT2gAA
hNoAAAcAAPABAAAA/////wcAMvABAAAA/////wAAAAABAAAAhgIAAIcCAACJAgAAigIAAK8C
AAC+AgAAvwIAANICAADdAgAABAMAAA0DAAAdBgAAJgYAALcHAAC4BwAA0AcAALAJAACxCQAA
HwsAADALAACOCwAAjwsAANULAADnDgAA6A4AAE0RAABOEQAAxxEAAN0RAAAMEgAASRIAAJIS
AADSEgAAURMAAJ4UAACfFAAAOBYAAEEYAABCGAAA/hgAAA0ZAAB/GwAAMhwAAKEcAADNHAAA
zhwAAKkgAACqIAAARyIAAIkiAACKIgAAziIAABwjAAD5IwAA3CQAADgmAABpJgAAjSYAAL4m
AAB6JwAALSgAAC4oAACeKQAAnykAAHwrAABRLAAAUiwAAGQsAACdLQAAfy4AAIEuAACgLgAA
zi4AAN4uAADzLgAABi8AABQvAAAiLwAAWS8AAHAwAACRMAAA0jAAANMwAAABMQAAKTEAAE4x
AACKMQAAqDEAAMsxAAD5MQAAJTIAAFAyAACNMgAAvzIAAOoyAAARMwAAOzMAAD0zAABUMwAA
lzMAAOQzAAAHNAAAKDQAADo0AABPNAAAYDQAAKY0AADRNAAAIDUAAGI1AACBNQAAkzUAAMM1
AADnNQAAGDYAAFw2AACSNgAAkzYAALQ2AAC1NgAAyDYAABo4AAAvOAAAdjgAAH04AABCOgAA
QzoAAEs6AADYPAAA2TwAAN88AAA9PQAAPj0AAEM9AACUPQAAlT0AAJw9AAD1PQAA9j0AAPs9
AABSPgAAUz4AAFk+AAC1PgAACT8AAOo/AADrPwAA8T8AAI9AAACQQAAAlUAAAFtBAABcQQAA
YUEAAJ5BAACfQQAApUEAANZBAADXQQAA3EEAAGRCAABlQgAAakIAAIZCAACHQgAACkMAAEND
AACQQwAAxkMAABVEAAB/RAAAwEQAADNFAAA0RQAAUEUAAMhGAADJRgAAzUYAAARIAAAFSAAA
C0gAACtKAAD6SgAA+0oAAAJLAAA0TAAANUwAADZMAACHTAAAiEwAAKVMAAD3TgAA+E4AAKJP
AABIUAAASVAAAHRQAAB1UAAAfFAAAC5RAAAoUgAAUlYAAC5XAAAvVwAANVcAABBYAADMWAAA
zVgAANJYAAAcWgAAHVoAAB5aAABCWgAAzFoAANJaAADAXQAAwV0AAMhdAAAHYAAACGAAABFg
AACCYQAAg2EAAI1hAABgYwAAYWMAAGdjAABeZAAAI2cAAB1pAAAeaQAAH2kAADhpAAAZawAA
GmsAAC1rAABEbQAARW0AAG9tAABwbQAAtW0AALZtAAAXcAAAGHAAABlwAADwcAAAWXMAAEh1
AACOdgAAQXcAAEJ3AACEeAAAhXgAADN6AACdegAAH3sAAIt7AAAGfwAAY38AADOAAACigQAA
RoIAAMKCAADGgwAAIIQAAC+HAAC5hwAAuocAANmHAADahwAAkokAAOmLAACHjQAAe5AAAH2Q
AADOkAAAE5EAADeRAABVkQAAnZEAALyRAADckQAA+5EAAPyRAAAvkwAAeJMAAJWTAACxkwAA
1JMAAPWTAAAXlAAAIpQAAD+UAABBlAAASpQAANmUAACGlQAAh5UAAJOWAACUlgAABpcAAEWX
AABrlwAAe5cAAJ6XAADDlwAA05cAAPiXAAAJmAAAMpgAAGWYAACOmAAAj5gAAJCYAAC9mAAA
z5gAAP+YAAAQmQAAPJkAAHKZAACemQAArpkAAOSZAAAYmgAAVJoAAFWaAABWmgAAhpsAAIeb
AABhnAAAYpwAAKidAACpnQAArKAAAK2gAACuoAAAr6AAALCgAACxoAAAsqAAALOgAAC0oAAA
taAAAOigAAD1oAAADKEAAB2hAAAroQAAPaEAAD6hAAA/oQAATaEAAGShAAByoQAAhKEAAJKh
AACkoQAApaEAACeiAAAoogAAzqIAAM+iAAAUpAAAFaQAABylAAAdpQAA+qYAAPumAAAzqAAA
NKgAADWoAAA2qAAAN6gAADioAABeqAAAU6kAAFSpAABiqQAAcKkAAI6pAADVqQAA/6kAAA2q
AAArqgAATqoAAHuqAACzqgAAtKoAALysAAC9rAAAO60AADytAABJrQAAZ60AAK6tAADZrQAA
560AAAWuAAAorgAAYK4AAIyuAACNrgAAS7AAAEywAABNsAAATrAAAE+wAABQsAAAiLAAAOSx
AADlsQAA97EAAAWyAAAcsgAAKrIAADmyAAA6sgAA8bIAAPKyAAAGtQAAB7UAACa1AAAkuQAA
qLoAAKm6AACqugAAq7oAAKy6AACtugAAr7oAAOe8AACsvQAAMb4AAEu+AAB5vgAA1b8AACDB
AAAuwgAA8cIAAI3DAAAQxQAAPcUAAOHFAAAGxgAAPMYAAGDGAACAxgAAqMcAAAPJAAAlyQAA
1MsAAPXLAAB3zQAAg80AAOHOAACi0AAApNAAALbRAADX0QAA2NEAANnRAADa0QAA6tEAAPHR
AAD20QAA/tEAAATSAAAF0gAAEtIAABPSAAAn0gAALNIAADXSAAA30gAAOdIAADrSAABP0gAA
V9IAAGLSAABk0gAAZtIAAGfSAAB80gAAhtIAAJHSAACT0gAAldIAAJbSAACr0gAAtNIAAL/S
AADB0gAAw9IAAMTSAADa0gAA49IAAO/SAADx0gAA89IAAPTSAAAK0wAAE9MAAB3TAAAf0wAA
IdMAACLTAAAz0wAAO9MAAEPTAABF0wAAR9MAAEjTAABa0wAAY9MAAGzTAABu0wAAcNMAAHHT
AACE0wAAj9MAAJnTAACb0wAAndMAAJ7TAACx0wAAudMAAMPTAADF0wAAx9MAAMjTAADc0wAA
49MAAO7TAADw0wAA8tMAAPPTAAAI1AAAEdQAABzUAAAe1AAAINQAACHUAAA21AAAQtQAAE3U
AABP1AAAUdQAAFLUAABn1AAActQAAH3UAAB/1AAAgdQAAILUAACY1AAAo9QAAK/UAACx1AAA
vNQAAL3UAADT1AAA3tQAAOvUAADt1AAA+NQAAPnUAAAK1QAAC9UAABrVAAAk1QAALNUAAC7V
AAA51QAAOtUAAEnVAABS1QAAW9UAAF3VAABo1QAAadUAAHfVAACA1QAAitUAAIzVAACW1QAA
l9UAAKTVAACs1QAAuNUAALrVAADM1QAAzdUAANrVAADh1QAA7dUAAO/VAAAJ1gAACtYAABfW
AAAe1gAAKtYAACzWAAA31gAAONYAAEHWAABI1gAAU9YAAFXWAABc1gAAXdYAAGbWAABx1gAA
fdYAAH/WAACq1gAAq9YAALTWAAC/1gAAy9YAAM3WAADV1gAA1tYAAOXWAADm1gAA79YAAPvW
AAAH1wAAEtcAACrXAAAr1wAANNcAAD/XAABL1wAAVtcAAGzXAABt1wAAd9cAAILXAACO1wAA
mdcAAKLXAACj1wAArdcAALjXAADE1wAAz9cAAAbYAAAH2AAAEdgAABzYAAAp2AAANNgAAEnY
AABK2AAAXtgAAF/YAABw2AAAe9gAAInYAACQ2AAAmtgAAJvYAACs2AAAt9gAAMXYAADN2AAA
6tgAAOvYAAAH2QAACNkAABnZAAAj2QAAK9kAADTZAABF2QAARtkAAFbZAABf2QAAZ9kAAHDZ
AABy2QAAc9kAAIDZAACB2QAAkNkAAJfZAACi2QAArdkAAK/ZAACw2QAAv9kAAMbZAADR2QAA
2tkAANzZAADd2QAA6tkAAOvZAAD62QAABdoAABHaAAAc2gAAHtoAAB/aAAAu2gAANtoAAEHa
AABK2gAAUdoAAFLaAABT2gAAVNoAAF3aAABe2gAAX9oAAGraAABt2gAAbtoAAG/aAABw2gAA
ftoAAH/aAACA2gAAgdoAAILaAACF2gAAmgAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5oA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeaAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAH
mgAAABswAAAAAAAAAIAAAACAAAAAAAAAAACAB5oAAAAmMAAAAAAAAACAAAAAgAAAAAAAAAAA
gAeaAAAAJjAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmgAAACYwAAAAAAAAAIAAAACAAAAAAAAA
AACAB5oAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeaAAAAGzAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAHmgAAABswAAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAAeaAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmgAAAAAwAAAAAAAAAIAAAACA
AAAAmAAAAAAABwoADyABMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeaAAAAADAAAAAAAAAAgB0G
AAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIAdBgAAAAAAAAAAAAAABwoADyABMAEAAAAAAACA
AAAAgAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgLgHAAAAAAAAAAAAAIAHmgAAAAAwAAAAAAAA
AIC4BwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAuAcAAAAAAAAAAAAAAAcKAA8gATACAAAA
AAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIAfCwAAAAAAAAAAAACAB5oAAAAAMAAA
AAAAAACAHwsAAAAAAAAAAAAAAAcKAAAAATAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAAAw
AAAAAAAAAICPCwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAjwsAAAAAAAAAAAAAAAeaAAAA
ADAAAAAAAAAAgI8LAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAICPCwAAAAAAAAAAAAAAB5oA
AAAAMAAAAAAAAACAjwsAAAAAAAAAAAAAAAeaACEgADAAAAAAAAAAgI8LAAAAAAAAAAAAAAAH
mgAhIAAwAQAAAAAAAICPCwAAAAAAAAAAAACAB5oAISAAMAIAAAAAAACAjwsAAAAAAAAAAAAA
gAeaACEgADADAAAAAAAAgI8LAAAAAAAAAAAAAAAHmgAhIAAwBAAAAAAAAICPCwAAAAAAAAAA
AACAB5oAISAAMAUAAAAAAACAjwsAAAAAAAAAAAAAgAeaACEgADAGAAAAAAAAgI8LAAAAAAAA
AAAAAAAHmgAAAAAwAAAAAAAAAICPCwAAAAAAAAAAAACAB5oAAAAAMAAAAAAAAACAjwsAAAAA
AAAAAAAAAAeaAAAAADAAAAAAAAAAgI8LAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAICPCwAA
AAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAjwsAAAAAAAAAAAAAAAcKAAAAATAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA
/hgAAAAAAAAAAAAAAAeaAAggADAAAAAAAAAAgP4YAAAAAAAAAAAAAAAHmgAIIAAwAQAAAAAA
AID+GAAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAAAeaAAAAADAAAAAA
AAAAgP4YAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAAAAB5oAAAAAMAAA
AAAAAACA/hgAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAAAHmgAAAAAw
AAAAAAAAAID+GAAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAAAeaAAAA
ADAAAAAAAAAAgP4YAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAAAAB5oA
AAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAAAH
mgAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAA
AAeaAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAID+GAAAAAAAAAAA
AAAAB5oAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgP4YAAAAAAAA
AAAAAAAHmgAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA/hgAAAAA
AAAAAAAAAAeaAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAID+GAAA
AAAAAAAAAAAABxoAAAACMAAAAAAAAACA/hgAAAAAAAAAAAAAAAcaAAAAAjAAAAAAAAAAgP4Y
AAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDaKwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA
2isAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgNorAAAAAAAAAAAAAAAHKgAAAAMwAAAAAAAA
AIDaKwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACACS4AAAAAAAAAAAAAAAeaABkgADAAAAAA
AAAAgAkuAAAAAAAAAAAAAAAHmgAZIAAwAQAAAAAAAIAJLgAAAAAAAAAAAACAB5oAGSAAMAIA
AAAAAACACS4AAAAAAAAAAAAAgAeaABkgADADAAAAAAAAgAkuAAAAAAAAAAAAAIAHmgAZIAAw
BAAAAAAAAIAJLgAAAAAAAAAAAACAB5oAGSAAMAUAAAAAAACACS4AAAAAAAAAAAAAAAeaAAAA
ADAAAAAAAAAAgJ4tAAAAAAAAAAAAAIAHKgAAAAMwAAAAAAAAAIBvKwAAAAAAAAAAAAAAB5oA
AAAAMAAAAAAAAACAii8AAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgIovAAAAAAAAAAAAAAAH
mgAiIAAwAAAAAAAAAICKLwAAAAAAAAAAAAAAB5oAIiAAMAEAAAAAAACAii8AAAAAAAAAAAAA
AAeaACIgADACAAAAAAAAgIovAAAAAAAAAAAAAIAHmgAiIAAwAwAAAAAAAIB2LwAAAAAAAAAA
AAAAB5oAIiAAMAQAAAAAAACA9S0AAAAAAAAAAAAAgAeaACIgADAFAAAAAAAAgPUtAAAAAAAA
AAAAAIAHmgAAAAAwAAAAAAAAAID1LQAAAAAAKAAAAAAAB5oAAAAAMAAAAAAAAACA9S0AAAAA
AHAAAAAAAAeaAAAAADAAAAAAAAAAgPUtAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAID1LQAA
AAAAIAAAAACAB5oAAAAAMAAAAAAAAACA9S0AAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgPUt
AAAAAAAgAAAAAIAHmgAAAAAwAAAAAAAAAID1LQAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA
9S0AAAAAACAAAAAAgAeaAAAAADAAAAAAAAAAgPUtAAAAAAAAAAAAAAAHKgAAAAMwAAAAAAAA
AIDaKQAAAAAAAAAAAAAAB5oAAAAVMAAAAAAAAACAqzAAAAAAADAAAAAAAAeaAAAAFTAAAAAA
AAAAgKswAAAAAAAwAAAAAAAHmgAAABUwAAAAAAAAAICrMAAAAAAAMAAAAAAAB5oAAAAVMAAA
AAAAAACAqzAAAAAAADAAAAAAAAeaAAAAFTAAAAAAAAAAgKswAAAAAAAwAAAAAAAHmgAAABUw
AAAAAAAAAICrMAAAAAAAMAAAAAAAB5oAAAAVMAAAAAAAAACAqzAAAAAAAAAAAAAAAAeaAAAA
FTAAAAAAAAAAgKswAAAAAAAwAAAAAAAHmgAAABUwAAAAAAAAAICrMAAAAAAAMAAAAAAAB5oA
AAAVMAAAAAAAAACAqzAAAAAAADAAAAAAAAeaAAAAFTAAAAAAAAAAgKswAAAAAAAwAAAAAAAH
mgAAABUwAAAAAAAAAICrMAAAAAAAMAAAAAAAB5oAAAAVMAAAAAAAAACAqzAAAAAAADAAAAAA
AAeaAAAAFTAAAAAAAAAAgKswAAAAAAAwAAAAAAAHmgAAABUwAAAAAAAAAICrMAAAAAAAmAAA
AAAAB5oAAAAVMAAAAAAAAACAqzAAAAAAAAAAAAAAAAeaAAAAFTAAAAAAAAAAgKswAAAAAACY
AAAAAAAHmgAAABUwAAAAAAAAAICrMAAAAAAAIAAAAACAB5oAAAAVMAAAAAAAAACAqzAAAAAA
ACAAAAAAgAeaAAAAADAAAAAAAAAAgKswAAAAAACYAAAAAAAHmgAAAAAwAAAAAAAAAICrMAAA
AAAAIAAAAACABxoAAAACMAAAAAAAAACAKhgAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgOsz
AAAAAACYAAAAAAAHKgAAAAMwAAAAAAAAAIDrMwAAAAAAIAAAAACAB5oAAAAAMAAAAAAAAACA
QDUAAAAAAAAAAAAAAAerAAAAFjAAAAAAAAAAgEA1AAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBANQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACAQDUAAAEAAOwAAAAAIAerAAAAFjAAAAAA
AAAAgEA1AAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBANQAAAQAA6AAAAAAgB5sAAAAAMAAA
AAAAAACAQDUAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEA1AAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBANQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACAQDUAAAEAAOwAAAAAIAerAAAA
FjAAAAAAAAAAgEA1AAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBANQAAAQAA6AAAAAAgB5sA
AAAAMAAAAAAAAACAQDUAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEA1AAABAADoAAAAACAH
qwAAAAAwAAAAAAAAAIBANQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACAQDUAAAEAAOwAAAAA
IAerAAAAFjAAAAAAAAAAgEA1AAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBANQAAAQAA6AAA
AAAgB5sAAAAAMAAAAAAAAACAQDUAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEA1AAABAADo
AAAAACAHqwAAAAAwAAAAAAAAAIBANQAAAQAAAAAAAAAAB6sAAAAAMAAAAAAAAACAQDUAAAEA
AAAAAAAAAAerAAAAADAAAAAAAAAAgEA1AAABAAAAAAAAACAHmwAAAAAwAAAAAAAAAIBANQAA
AQAA7AAAAAAgB6sAAAAWMAAAAAAAAACAQDUAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEA1
AAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBANQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACA
QDUAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEA1AAABAADoAAAAACAHmwAAAAAwAAAAAAAA
AIBANQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACAQDUAAAEAAOgAAAAAIAerAAAAADAAAAAA
AAAAgEA1AAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBANQAAAQAA7AAAAAAgB6sAAAAWMAAA
AAAAAACAQDUAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEA1AAABAADoAAAAACAHmwAAAAAw
AAAAAAAAAIBANQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACAQDUAAAEAAOgAAAAAIAerAAAA
ADAAAAAAAAAAgEA1AAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBANQAAAQAA7AAAAAAgB6sA
AAAWMAAAAAAAAACAQDUAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEA1AAABAADoAAAAACAH
mwAAAAAwAAAAAAAAAIBANQAAAQAA7AAAAAAgB5oAAAAAMAAAAAAAAACAQDUAAAAAAAAAAAAA
gAeaAAggGDACAAAAAAAAgEA1AAAAAABwAAAAAAAHmgAIIBgwAwAAAAAAAIBANQAAAAAAAAAA
AAAAB5oACCAYMAQAAAAAAACAQDUAAAAAAAAAAAAAAAeaAAggGDAFAAAAAAAAgEA1AAAAAABw
AAAAAAAHmgAIIBgwBgAAAAAAAIBANQAAAAAAcAAAAAAAB5oACCAYMAcAAAAAAACAQDUAAAAA
AHAAAAAAAAeaAAAAADAAAAAAAAAAgEA1AAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIBANQAA
AAAAcAAAAAAAByoAAAADMAAAAAAAAACA6zMAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgEdC
AAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIBHQgAAAAAAAAAAAAAAB6sAAAAWMAAAAAAAAACA
R0IAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEdCAAABAADoAAAAACAHmwAAAAAwAAAAAAAA
AIBHQgAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACAR0IAAAEAAOgAAAAAIAerAAAAADAAAAAA
AAAAgEdCAAABAADoAAAAAAAHqwAAAAAwAAAAAAAAAIBHQgAAAQAA6AAAAAAgB5sAAAAAMAAA
AAAAAACAR0IAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEdCAAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBHQgAAAQAAAAAAAAAgB5sAAAAAMAAAAAAAAACAR0IAAAEAAOwAAAAAIAcqAAAA
AzAAAAAAAAAAgOszAAAAAAAAAAAAAIAHmgAAAAAwAAAAAAAAAIA4SQAAAAAASAAAAAAAByoA
AAADMAAAAAAAAACA6zMAAAAAAEgAAAAAAAcqAAAAAzAAAAAAAAAAgOszAAAAAABIAAAAAAAH
mgAAAAAwAAAAAAAAAICLSQAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAi0kAAAAAAAAAAAAA
AAeaAAAAADAAAAAAAAAAgItJAAAAAABIAAAAAAAHmgAAAAAwAAAAAAAAAICLSQAAAAAAmAAA
AAAAB5oAAAAAMAAAAAAAAACAi0kAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgItJAAAAAABI
AAAAAAAHmgAAAAAwAAAAAAAAAICLSQAAAAAASAAAAAAAB6sAAAAWMAAAAAAAAACAi0kAAAEA
AOgAAAAAIAerAAAAADAAAAAAAAAAgItJAAABAADoAAAAAAAHqwAAAAAwAAAAAAAAAICLSQAA
AQAA6AAAAAAAB6sAAAAAMAAAAAAAAACAi0kAAAEAAOgAAAAAAAerAAAAADAAAAAAAAAAgItJ
AAABAADoAAAAACAHmwAAAAAwAAAAAAAAAICLSQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACA
i0kAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgItJAAABAADoAAAAAAAHqwAAAAAwAAAAAAAA
AICLSQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACAi0kAAAEAAOwAAAAAIAerAAAAFjAAAAAA
AAAAgItJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAICLSQAAAQAA6AAAAAAgB5sAAAAAMAAA
AAAAAACAi0kAAAEAAOwAAAAAIAeaAAAAADAAAAAAAAAAgItJAAAAAAAAAAAAAIAHmgAAAAAw
AAAAAAAAAICLSQAAAAAAUAAAAAAAB5oAAAAAMAAAAAAAAACAi0kAAAAAAFAAAAAAAAerAAAA
FjAAAAAAAAAAgItJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAICLSQAAAQAAAAAAAAAgB5kA
AAAAMAAAAAAAAACAi0kAAAEAAOwAAAAAIAWrAAAAFjAAAAAAAAAAgItJAAABAADoAAAAACAH
qwAAAAAwAAAAAAAAAICLSQAAAQAA6AAAAAAgB5kAAAAAMAAAAAAAAACAi0kAAAEAAOwAAAAA
IAWrAAAAFjAAAAAAAAAAgItJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAICLSQAAAQAA6AAA
AAAgB5kAAAAAMAAAAAAAAACAi0kAAAEAAOwAAAAAIAWrAAAAFjAAAAAAAAAAgItJAAABAADo
AAAAACAHqwAAAAAwAAAAAAAAAICLSQAAAQAA6AAAAAAgB5kAAAAAMAAAAAAAAACAi0kAAAEA
AOwAAAAAIAWrAAAAFjAAAAAAAAAAgItJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAICLSQAA
AQAA6AAAAAAAB6sAAAAAMAAAAAAAAACAi0kAAAEAAOgAAAAAAAerAAAAADAAAAAAAAAAgItJ
AAABAAAAAAAAACAHmQAAAAAwAAAAAAAAAICLSQAAAQAA7AAAAAAgBZoAAAAAMAAAAAAAAACA
i0kAAAAAAAAAAAAAgAcaAAAAAjAAAAAAAAAAgCoYAAAAAABgAAAAAAAHmgAAAAAwAAAAAAAA
AIBtZQAAAAAAYAAAAAAABxoAAAACMAAAAAAAAACAKhgAAAAAAGAAAAAAAAcaAAAAAjAAAAAA
AAAAgCoYAAAAAACYAAAAAAAHmgAAAAAwAAAAAAAAAIBkZwAAAAAAAAAAAAAAB5oAAAAAMAAA
AAAAAACAZGcAAAAAAHAAAAAAAAcaAAAAAjAAAAAAAAAAgCoYAAAAAABoAAAAAAAHmgAAAAAw
AAAAAAAAAICLaQAAAAAAaAAAAAAAB5oAAAAAMAAAAAAAAACAi2kAAAAAAGgAAAAAAAeaAAAA
ADAAAAAAAAAAgItpAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAICLaQAAAAAAAAAAAAAAB5oA
AAAAMAAAAAAAAACAi2kAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgItpAAAAAABoAAAAAAAH
mgAAAAAwAAAAAAAAAICLaQAAAAAAaAAAAAAAB5oAAAAAMAAAAAAAAACAi2kAAAAAAJgAAAAA
AAeaAAAAADAAAAAAAAAAgItpAAAAAABoAAAAAAAHmgAAAAAwAAAAAAAAAICLaQAAAAAAAAAA
AAAAB5oAAAAAMAAAAAAAAACAi2kAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgItpAAAAAABw
AAAAAAAHmgAAAAAwAAAAAAAAAICLaQAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAi2kAAAAA
AJgAAAAAAAeaAAAAADAAAAAAAAAAgItpAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAICLaQAA
AAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAi2kAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgItp
AAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAICLaQAAAAAAcAAAAAAAB5pAAAAAMAAAAAAAAACA
i2kAAAAAAHgAAAAAAAeaQAAAADAAAAAAAAAAgItpAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAA
AICLaQAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAi2kAAAAAAHAAAAAAAAeaAAAAADAAAAAA
AAAAgItpAAAAAAB4AAAAAAAHmgAAAAAwAAAAAAAAAICLaQAAAAAAeAAAAAAAB5oAAAAAMAAA
AAAAAACAi2kAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgItpAAAAAAB4AAAAAAAHmgAAAAAw
AAAAAAAAAICLaQAAAAAAgAAAAAAAB5oAAAAAMAAAAAAAAACAi2kAAAAAAIAAAAAAAAcKAAAA
ATAAAAAAAAAAgAAAAIAAAACAAAAAAAgHmgAAAAAwAAAAAAAAAIDHgwAAAAAAgAAAAAAAB5oA
AAAAMAAAAAAAAACAx4MAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAABwAAAAAAAH
mgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAIAAAAAA
AAeaAAAAADAAAAAAAAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAA
AAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAIgAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAABw
AAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAA
AHAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAA
AAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgMeD
AAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACA
x4MAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAA
AIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAHAAAAAAAAeaAAAAADAAAAAA
AAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAA
AAAAAACAx4MAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACQAAAAAAAHmgAAAAAw
AAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAHAAAAAAAAeaAAAA
ADAAAAAAAAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAkAAAAAAAB5oA
AAAAMAAAAAAAAACAx4MAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACQAAAAAAAH
mgAAAAAwAAAAAAAAAIDHgwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAHAAAAAA
AAeaAAAAADAAAAAAAAAAgMeDAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAAAAA
AAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAABw
AAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAA
AHAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAA
AAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgMeD
AAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACA
x4MAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAA
AIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAHAAAAAAAAeaAAAAADAAAAAA
AAAAgMeDAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAA
AAAAAACAx4MAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAAAgAAAAAIAHmgAAAAAw
AAAAAAAAAIDHgwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAACAAAAAAgAeaAAAA
ADAAAAAAAAAAgMeDAAAAAAAgAAAAAIAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAIAAAAACAB5oA
AAAAMAAAAAAAAACAx4MAAAAAABgAAAAAgAeaAAAAADAAAAAAAAAAgMeDAAAAAAAYAAAAAIAH
mgAAAAAwAAAAAAAAAIDHgwAAAAAAKAAAAACAB5oAAAAAMAAAAAAAAACAx4MAAAAAACAAAAAA
gAeaAAAAADAAAAAAAAAAgMeDAAAAAAAoAAAAAIAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAAAAA
AAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAAAA
AAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAA
AJgAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACQAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAA
AAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgMeD
AAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACA
x4MAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAA
AIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJgAAAAAAAeaAAAAADAAAAAA
AAAAgMeDAAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAA
AAAAAACAx4MAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAw
AAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJgAAAAAAAeaAAAA
ADAAAAAAAAAAgMeDAAAAAACYAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oA
AAAAMAAAAAAAAACAx4MAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACYAAAAAAAH
mgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJgAAAAA
AAeaAAAAADAAAAAAAAAAgMeDAAAAAACYAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAA
AAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACY
AAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAA
AJgAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACYAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAA
AAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgMeD
AAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACA
x4MAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACYAAAAAAAHmgAAAAAwAAAAAAAA
AIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJgAAAAAAAeaAAAAADAAAAAA
AAAAgMeDAAAAAACYAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAA
AAAAAACAx4MAAAAAAKAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAw
AAAAAAAAAIDHgwAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAKAAAAAAAAeaAAAA
ADAAAAAAAAAAgMeDAAAAAACgAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAAAAAAAAAB5oA
AAAAMAAAAAAAAACAx4MAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACgAAAAAAAH
mgAAAAAwAAAAAAAAAIDHgwAAAAAAoAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAKAAAAAA
AAeaAAAAADAAAAAAAAAAgMeDAAAAAACgAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAoAAA
AAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAKAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACg
AAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAA
AKAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAA
AAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAKAAAAAAAAeaAAAAADAAAAAAAAAAgMeD
AAAAAACgAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAoAAAAAAAB5oAAAAAMAAAAAAAAACA
x4MAAAAAAKAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACgAAAAAAAHmgAAAAAwAAAAAAAA
AIDHgwAAAAAAoAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAKAAAAAAAAeaAAAAADAAAAAA
AAAAgMeDAAAAAACgAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAoAAAAAAAB5oAAAAAMAAA
AAAAAACAx4MAAAAAAKAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACgAAAAAAAHmgAAAAAw
AAAAAAAAAIDHgwAAAAAAoAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAOgAAAAAAAeaAAAA
ADAAAAAAAAAAgMeDAAAAAACoAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAqAAAAAAAB5oA
AAAAMAAAAAAAAACAx4MAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAABwAAAAAAAH
mgAAAAAwAAAAAAAAAIDHgwAAAAAAmAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAKgAAAAA
AAeaAAAAADAAAAAAAAAAgMeDAAAAAACoAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAqAAA
AAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAKgAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACo
AAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAA
AAAAAAAAAAeaAAAAADAAAAAAAAAAgMeDAAAAAACoAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAA
AAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAx4MAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgMeD
AAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIDHgwAAAAAAqAAAAAAABxoAAAACMAAAAAAAAACA
x4MAAAAAAJgAAAAAAAcaAAAAAjAAAAAAAAAAgMeDAAAAAACoAAAAAAAHmgAAAAAwAAAAAAAA
AIAAsQAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACAALEAAAAAAAAAAAAAAAeaAAAAADAAAAAA
AAAAgACxAAAAAACwAAAAAAAHmgAAAAAwAAAAAAAAAIAAsQAAAAAAcAAAAAAAB5oAAAAAMAAA
AAAAAACAALEAAAAAALAAAAAAAAeaAAAAADAAAAAAAAAAgACxAAAAAACwAAAAAAAHmgAAAAAw
AAAAAAAAAIAAsQAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAALEAAAAAALAAAAAAAAeaAAAA
ADAAAAAAAAAAgACxAAAAAAAAAAAAAIAHmgAAAAAwAAAAAAAAAIAAsQAAAAAAsAAAAAAAB5oA
AAAAMAAAAAAAAACAALEAAAAAALgAAAAAAAcKAAAAATAAAAAAAAAAgAAAAIAAAABwAAAAAAAH
GgAAAAIwAAAAAAAAAIAnugAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACAQboAAAAAAHAAAAAA
AAeaAAAAADAAAAAAAAAAgEG6AAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAIBBugAAAAAAcAAA
AAAAB5oAAAAAMAAAAAAAAACAQboAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgEG6AAAAAABw
AAAAAAAHmgAAAAAwAAAAAAAAAIBBugAAAAAAmAAAAAAABxoAAAACMAAAAAAAAACAJ7oAAAAA
AAAAAAAAAAeaAAAAADAAAAAAAAAAgObAAAAAAABwAAAAAAAHmgAIIBgwCAAAAAAAAIDmwAAA
AAAAAAAAAAAAB5oACCAYMAkAAAAAAACA5sAAAAAAAHAAAAAAAAeaAAggGDAKAAAAAAAAgObA
AAAAAAAAAAAAAAAHmgAIIBgwCwAAAAAAAIDmwAAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACA
5sAAAAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgObAAAAAAAC4AAAAAAAHGgAAAAIwAAAAAAAA
AIAnugAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACA1cQAAAAAAHAAAAAAAAcaAAAAAjAAAAAA
AAAAgCe6AAAAAABwAAAAAAAHmgAAAAAwAAAAAAAAAICmxwAAAAAAcAAAAAAABwoAAAABMAAA
AAAAAACAAAAAgAAAAHAAAAAAAAeaAAAAADAAAAAAAAAAgEXJAAAAAAAAAAAAAAAHmgAAAAAw
AAAAAAAAAIBFyQAAAAAAcAAAAAAAB5oAAAAAMAAAAAAAAACARckAAAAAAHAAAAAAAAeaAAAA
FzAAAAAAAAAAgEXJAAAAAADIAAAAAAAHmgAAAAAwAAAAAAAAAIBFyQAAAAAAcAAAAAAAB5oA
AAAAMAAAAAAAAACARckAAAAAAJgAAAAAAAeaAAAAADAAAAAAAAAAgEXJAAAAAADIAAAAAAAH
mgAAAAAwAAAAAAAAAIBFyQAAAAAAcAAAAAAAB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADo
AAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEA
AOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJ
AAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACA
RckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAA
AAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAA
AAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAA
ADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sA
AAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAH
qwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADs
AAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEA
AOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJ
AAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACA
RckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAA
AAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAA
AAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAA
ADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sA
AAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAH
qwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADo
AAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEA
AOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJ
AAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACA
RckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAA
AAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAA
AAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAA
ADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sA
AAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAH
qwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADs
AAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEA
AOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJ
AAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACA
RckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAA
AAAAgEXJAAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAA
AAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAA
ADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sA
AAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJAAABAADoAAAAACAH
qwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB5sAAAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJAAABAADo
AAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEA
AOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB5sAAAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJ
AAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACA
RckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAAFjAAAAAA
AAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAA
AAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAA
FjAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sA
AAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAH
qwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACARckAAAEAAOwAAAAA
IAerAAAAFjAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADo
AAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACARckAAAEA
AOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJ
AAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sAAAAAMAAAAAAAAACA
RckAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAA
AAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sAAAAAMAAA
AAAAAACARckAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAA
ADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sA
AAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAH
mwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADo
AAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACARckAAAEA
AOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJ
AAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACA
RckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAA
AAAAgEXJAAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAWMAAA
AAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAA
ADAAAAAAAAAAgEXJAAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sA
AAAWMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAH
qwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADs
AAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEA
AOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJ
AAABAADsAAAAACAHqwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACA
RckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAA
AAAAgEXJAAABAADsAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sAAAAAMAAA
AAAAAACARckAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAA
ADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB5sA
AAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAAFjAAAAAAAAAAgEXJAAABAADoAAAAACAH
qwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB5sAAAAAMAAAAAAAAACARckAAAEAAOwAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADo
AAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACARckAAAEA
AOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAA
AQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJ
AAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAWMAAAAAAAAACA
RckAAAEAAOgAAAAAIAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAA
AIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAAADAAAAAA
AAAAgEXJAAABAADoAAAAACAHmwAAAAAwAAAAAAAAAIBFyQAAAQAA7AAAAAAgB6sAAAAAMAAA
AAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAHqwAAABYw
AAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAerAAAA
ADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sA
AAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADsAAAAACAH
qwAAABYwAAAAAAAAAIBFyQAAAQAA6AAAAAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAA
IAerAAAAADAAAAAAAAAAgEXJAAABAADoAAAAACAHqwAAAAAwAAAAAAAAAIBFyQAAAQAA6AAA
AAAgB6sAAAAAMAAAAAAAAACARckAAAEAAOgAAAAAIAebAAAAADAAAAAAAAAAgEXJAAABAADs
AAAAACAHmgAAAAAwAAAAAAAAAIBFyQAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACARckAAAAA
AAAAAAAAAAeaQAAADzAAAAAAAAAAgAAAAIAAAAABAAAAAIAHmEAAAA8wAAAAAAAAAIAAAACA
AAAAAAAAAACAAZhAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAGYQAAADzAAAAAAAAAAgAAA
AIAAAAABAAAAAAABmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJpAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAgAeaQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmkAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAACAB5pAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeaQAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAIAHmkAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACABwoAAAAAMAAA
AAAAAAAAAAAAAAAA3B6ZBwQAAAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAACABwAAAAABAAAAhgIAAIcCAACJAgAAigIAAK8CAAC+AgAA
vwIAANICAADdAgAABAMAAA0DAAAdBgAAJgYAALcHAAC4BwAA0AcAALAJAACxCQAAHwsAADAL
AACOCwAAjwsAANULAADnDgAA6A4AAE0RAABOEQAAxxEAAN0RAAAMEgAASRIAAJISAADSEgAA
URMAAJ4UAACfFAAAOBYAAEEYAABCGAAA/hgAAA0ZAAB/GwAAMhwAAKEcAADNHAAAzhwAAKkg
AACqIAAARyIAAIkiAACKIgAAziIAABwjAAD5IwAA3CQAADgmAABpJgAAjSYAAL4mAAB6JwAA
LSgAAC4oAACeKQAAnykAAHwrAABRLAAAUiwAAGQsAACdLQAAfy4AAIEuAACgLgAAzi4AAN4u
AADzLgAABi8AABQvAAAiLwAAWS8AAHAwAACRMAAA0jAAANMwAAABMQAAKTEAAE4xAACKMQAA
qDEAAMsxAAD5MQAAJTIAAFAyAACNMgAAvzIAAOoyAAARMwAAOzMAAD0zAABUMwAAlzMAAOQz
AAAHNAAAKDQAADo0AABPNAAAYDQAAKY0AADRNAAAIDUAAGI1AACBNQAAkzUAAMM1AADnNQAA
GDYAAFw2AACSNgAAkzYAALQ2AAC1NgAAyDYAABo4AAAvOAAAdjgAAH04AABCOgAAQzoAAEs6
AADYPAAA2TwAAN88AAA9PQAAPj0AAEM9AACUPQAAlT0AAJw9AAD1PQAA9j0AAPs9AABSPgAA
Uz4AAFk+AAC1PgAACT8AAOo/AADrPwAA8T8AAI9AAACQQAAAlUAAAFtBAABcQQAAYUEAAJ5B
AACfQQAApUEAANZBAADXQQAA3EEAAGRCAABlQgAAakIAAIZCAACHQgAACkMAAENDAACQQwAA
xkMAABVEAAB/RAAAwEQAADNFAAA0RQAAUEUAAMhGAADJRgAAzUYAAARIAAAFSAAAC0gAACtK
AAD6SgAA+0oAAAJLAAA0TAAANUwAADZMAACHTAAAiEwAAKVMAAD3TgAA+E4AAKJPAABIUAAA
SVAAAHRQAAB1UAAAfFAAAC5RAAAoUgAAUlYAAC5XAAAvVwAANVcAABBYAADMWAAAzVgAANJY
AAAcWgAAHVoAAB5aAABCWgAAzFoAANJaAADAXQAAwV0AAMhdAAAHYAAACGAAABFgAACCYQAA
g2EAAI1hAABgYwAAYWMAAGdjAABeZAAAI2cAAB1pAAAeaQAAH2kAADhpAAAZawAAGmsAAC1r
AABEbQAARW0AAG9tAABwbQAAtW0AALZtAAAXcAAAGHAAABlwAADwcAAAWXMAAEh1AACOdgAA
QXcAAEJ3AACEeAAAhXgAADN6AACdegAAH3sAAIt7AAAGfwAAY38AADOAAACigQAARoIAAMKC
AADGgwAAIIQAAC+HAAC5hwAAuocAANmHAADahwAAkokAAOmLAACHjQAAe5AAAH2QAADOkAAA
E5EAADeRAABVkQAAnZEAALyRAADckQAA+5EAAPyRAAAvkwAAeJMAAJWTAACxkwAA1JMAAPWT
AAAXlAAAIpQAAD+UAABBlAAASpQAANmUAACGlQAAh5UAAJOWAACUlgAABpcAAEWXAABrlwAA
e5cAAJ6XAADDlwAA05cAAPiXAAAJmAAAMpgAAGWYAACOmAAAj5gAAJCYAAC9mAAAz5gAAP+Y
AAAQmQAAPJkAAHKZAACemQAArpkAAOSZAAAYmgAAVJoAAFWaAABWmgAAhpsAAIebAABhnAAA
YpwAAKidAACpnQAArKAAAK2gAACuoAAAr6AAALCgAACxoAAAsqAAALOgAAC0oAAAtaAAAOig
AAD1oAAADKEAAB2hAAAroQAAPaEAAD6hAAA/oQAATaEAAGShAAByoQAAhKEAAJKhAACkoQAA
paEAACeiAAAoogAAzqIAAM+iAAAUpAAAFaQAABylAAAdpQAA+qYAAPumAAAzqAAANKgAADWo
AAA2qAAAN6gAADioAABeqAAAU6kAAFSpAABiqQAAcKkAAI6pAADVqQAA/6kAAA2qAAArqgAA
TqoAAHuqAACzqgAAtKoAALysAAC9rAAAO60AADytAABJrQAAZ60AAK6tAADZrQAA560AAAWu
AAAorgAAYK4AAIyuAACNrgAAS7AAAEywAABNsAAATrAAAE+wAABQsAAAiLAAAOSxAADlsQAA
97EAAAWyAAAcsgAAKrIAADmyAAA6sgAA8bIAAPKyAAAGtQAAB7UAACa1AAAkuQAAqLoAAKm6
AACqugAAq7oAAKy6AACtugAAr7oAAOe8AACsvQAAMb4AAEu+AAB5vgAA1b8AACDBAAAuwgAA
8cIAAI3DAAAQxQAAPcUAAOHFAAAGxgAAPMYAAGDGAACAxgAAqMcAAAPJAAAlyQAA1MsAAPXL
AAB3zQAAg80AAOHOAACi0AAApNAAALbRAADX0QAA2NEAANnRAADa0QAA6tEAAPHRAAD20QAA
/tEAAATSAAAF0gAAEtIAABPSAAAn0gAALNIAADXSAAA30gAAOdIAADrSAABP0gAAV9IAAGLS
AABk0gAAZtIAAGfSAAB80gAAhtIAAJHSAACT0gAAldIAAJbSAACr0gAAtNIAAL/SAADB0gAA
w9IAAMTSAADa0gAA49IAAO/SAADx0gAA89IAAPTSAAAK0wAAE9MAAB3TAAAf0wAAIdMAACLT
AAAz0wAAO9MAAEPTAABF0wAAR9MAAEjTAABa0wAAY9MAAGzTAABu0wAAcNMAAHHTAACE0wAA
j9MAAJnTAACb0wAAndMAAJ7TAACx0wAAudMAAMPTAADF0wAAx9MAAMjTAADc0wAA49MAAO7T
AADw0wAA8tMAAPPTAAAI1AAAEdQAABzUAAAe1AAAINQAACHUAAA21AAAQtQAAE3UAABP1AAA
UdQAAFLUAABn1AAActQAAH3UAAB/1AAAgdQAAILUAACY1AAAo9QAAK/UAACx1AAAvNQAAL3U
AADT1AAA3tQAAOvUAADt1AAA+NQAAPnUAAAK1QAAC9UAABrVAAAk1QAALNUAAC7VAAA51QAA
OtUAAEnVAABS1QAAW9UAAF3VAABo1QAAadUAAHfVAACA1QAAitUAAIzVAACW1QAAl9UAAKTV
AACs1QAAuNUAALrVAADM1QAAzdUAANrVAADh1QAA7dUAAO/VAAAJ1gAACtYAABfWAAAe1gAA
KtYAACzWAAA31gAAONYAAEHWAABI1gAAU9YAAFXWAABc1gAAXdYAAGbWAABx1gAAfdYAAH/W
AACq1gAAq9YAALTWAAC/1gAAy9YAAM3WAADV1gAA1tYAAOXWAADm1gAA79YAAPvWAAAH1wAA
EtcAACrXAAAr1wAANNcAAD/XAABL1wAAVtcAAGzXAABt1wAAd9cAAILXAACO1wAAmdcAAKLX
AACj1wAArdcAALjXAADE1wAAz9cAAAbYAAAH2AAAEdgAABzYAAAp2AAANNgAAEnYAABK2AAA
XtgAAF/YAABw2AAAe9gAAInYAACQ2AAAmtgAAJvYAACs2AAAt9gAAMXYAADN2AAA6tgAAOvY
AAAH2QAACNkAABnZAAAj2QAAK9kAADTZAABF2QAARtkAAFbZAABf2QAAZ9kAAHDZAABy2QAA
c9kAAIDZAACB2QAAkNkAAJfZAACi2QAArdkAAK/ZAACw2QAAv9kAAMbZAADR2QAA2tkAANzZ
AADd2QAA6tkAAOvZAAD62QAABdoAABHaAAAc2gAAHtoAAB/aAAAu2gAANtoAAEHaAABK2gAA
UdoAAFLaAABT2gAAVNoAAIXaAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA
GzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAACYwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA
AAAmMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAJjAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAbMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAGzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAACAAPIAEwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAHQYAAAAA
AAAAAAAAgACYAAAAADAAAAAAAAAAgB0GAAAAAAAAAAAAAIAACAAPIAEwAQAAAAAAAIAAAACA
AAAAAAAAAACAAJgAAAAAMAAAAAAAAACAuAcAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgLgH
AAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIC4BwAAAAAAAAAAAACAAAgADyABMAIAAAAAAACA
AAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgB8LAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAA
AIAfCwAAAAAAAAAAAACAAAgAAAABMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAA
AAAAgI8LAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAICPCwAAAAAAAAAAAACAAJgAAAAAMAAA
AAAAAACAjwsAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgI8LAAAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAICPCwAAAAAAAAAAAACAAJgAISAAMAAAAAAAAACAjwsAAAAAAAAAAAAAgACYACEg
ADABAAAAAAAAgI8LAAAAAAAAAAAAAIAAmAAhIAAwAgAAAAAAAICPCwAAAAAAAAAAAACAAJgA
ISAAMAMAAAAAAACAjwsAAAAAAAAAAAAAgACYACEgADAEAAAAAAAAgI8LAAAAAAAAAAAAAIAA
mAAhIAAwBQAAAAAAAICPCwAAAAAAAAAAAACAAJgAISAAMAYAAAAAAACAjwsAAAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgI8LAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAICPCwAAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAjwsAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgI8LAAAAAAAA
AAAAAIAAmAAAAAAwAAAAAAAAAICPCwAAAAAAAAAAAACAAAgAAAABMAAAAAAAAACAAAAAgAAA
AAAAAAAAgACYAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAID+GAAA
AAAAAAAAAACAAJgACCAAMAAAAAAAAACA/hgAAAAAAAAAAAAAgACYAAggADABAAAAAAAAgP4Y
AAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA
/hgAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAA
AID+GAAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAgACYAAAAADAAAAAA
AAAAgP4YAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAACAAJgAAAAAMAAA
AAAAAACA/hgAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAID+GAAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgP4YAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAACAAJgA
AAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAID+GAAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgP4YAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAID+GAAAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACA/hgAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgP4YAAAAAAAA
AAAAAIAAGAAAAAIwAAAAAAAAAID+GAAAAAAAAAAAAACAABgAAAACMAAAAAAAAACA/hgAAAAA
AAAAAAAAgACYAAAAADAAAAAAAAAAgFIsAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIBSLAAA
AAAAAAAAAACAAJgAAAAAMAAAAAAAAACAUiwAAAAAAAAAAAAAgAAoAAAAAzAAAAAAAAAAgFIs
AAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAICBLgAAAAAAAAAAAACAAJgAGSAAMAAAAAAAAACA
gS4AAAAAAAAAAAAAgACYABkgADABAAAAAAAAgIEuAAAAAAAAAAAAAIAAmAAZIAAwAgAAAAAA
AICBLgAAAAAAAAAAAACAAJgAGSAAMAMAAAAAAACAgS4AAAAAAAAAAAAAgACYABkgADAEAAAA
AAAAgIEuAAAAAAAAAAAAAIAAmAAZIAAwBQAAAAAAAICBLgAAAAAAAAAAAACAAJgAAAAAMAAA
AAAAAACAgS4AAAAAAAAAAAAAgAAoAAAAAzAAAAAAAAAAgFIsAAAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAIBwMAAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAcDAAAAAAAAAAAAAAgACYACIg
ADAAAAAAAAAAgHAwAAAAAAAAAAAAAIAAmAAiIAAwAQAAAAAAAIBwMAAAAAAAAAAAAACAAJgA
IiAAMAIAAAAAAACAcDAAAAAAAAAAAAAAgACYACIgADADAAAAAAAAgHAwAAAAAAAAAAAAAIAA
mAAiIAAwBAAAAAAAAIBwMAAAAAAAAAAAAACAAJgAIiAAMAUAAAAAAACAcDAAAAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgCkwAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIApMAAAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAKTAAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgCkwAAAAAAAA
AAAAAIAAmAAAAAAwAAAAAAAAAIApMAAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAKTAAAAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgCkwAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIApMAAA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAKTAAAAAAAFAAAAAAgAAoAAAAAzAAAAAAAAAAgAss
AAAAAABQAAAAAIAAmAAAABUwAAAAAAAAAID2MgAAAAAAUAAAAACAAJgAAAAVMAAAAAAAAACA
9jIAAAAAAEAAAAAAgACYAAAAFTAAAAAAAAAAgPYyAAAAAABAAAAAAIAAmAAAABUwAAAAAAAA
AID2MgAAAAAAAAAAAAAAAJgAAAAVMAAAAAAAAACA9jIAAAAAAAAAAAAAAACYAAAAFTAAAAAA
AAAAgPYyAAAAAAAAAAAAAAAAmAAAABUwAAAAAAAAAID2MgAAAAAAQAAAAACAAJgAAAAVMAAA
AAAAAACA9jIAAAAAAEAAAAAAgACYAAAAFTAAAAAAAAAAgPYyAAAAAAAAAAAAAAAAmAAAABUw
AAAAAAAAAID2MgAAAAAAQAAAAACAAJgAAAAVMAAAAAAAAACA9jIAAAAAAAAAAAAAgACYAAAA
FTAAAAAAAAAAgPYyAAAAAABAAAAAAIAAmAAAABUwAAAAAAAAAID2MgAAAAAAQAAAAACAAJgA
AAAVMAAAAAAAAACA9jIAAAAAAEAAAAAAgACYAAAAFTAAAAAAAAAAgPYyAAAAAABAAAAAAIAA
mAAAABUwAAAAAAAAAID2MgAAAAAAQAAAAACAAJgAAAAVMAAAAAAAAACA9jIAAAAAAEAAAAAA
gACYAAAAFTAAAAAAAAAAgPYyAAAAAAAQAAAAAAAAmAAAABUwAAAAAAAAAID2MgAAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACA9jIAAAAAAEAAAAAAgACYAAAAADAAAAAAAAAAgPYyAAAAAABQ
AAAAAIAAGAAAAAIwAAAAAAAAAID+GAAAAAAAUAAAAACAAJgAAAAAMAAAAAAAAACAbjYAAAAA
AAAAAAAAAAAoAAAAAzAAAAAAAAAAgG42AAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIDTNwAA
AAAAUAAAAACAAKkAAAAWMAAAAAAAAACA0zcAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgNM3
AAABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIDTNwAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACA
0zcAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgNM3AAABAAAYAAAAACAAmQAAAAAwAAAAAAAA
AIDTNwAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACA0zcAAAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgNM3AAABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIDTNwAAAQAAHAAAAAAgAKkAAAAWMAAA
AAAAAACA0zcAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgNM3AAABAAAYAAAAACAAmQAAAAAw
AAAAAAAAAIDTNwAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACA0zcAAAEAABgAAAAAIACpAAAA
ADAAAAAAAAAAgNM3AAABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIDTNwAAAQAAHAAAAAAgAKkA
AAAWMAAAAAAAAACA0zcAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgNM3AAABAAAYAAAAACAA
mQAAAAAwAAAAAAAAAIDTNwAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACA0zcAAAEAABgAAAAA
IACpAAAAADAAAAAAAAAAgNM3AAABAAAYAAAAAAAAqQAAAAAwAAAAAAAAAIDTNwAAAQAAGAAA
AAAAAKkAAAAAMAAAAAAAAACA0zcAAAEAABgAAAAAIACZAAAAADAAAAAAAAAAgNM3AAABAAAc
AAAAACAAqQAAABYwAAAAAAAAAIDTNwAAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA0zcAAAEA
ABgAAAAAIACZAAAAADAAAAAAAAAAgNM3AAABAAAcAAAAACAAqQAAABYwAAAAAAAAAIDTNwAA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA0zcAAAEAABgAAAAAIACZAAAAADAAAAAAAAAAgNM3
AAABAAAcAAAAACAAqQAAABYwAAAAAAAAAIDTNwAAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA
0zcAAAEAABgAAAAAIACZAAAAADAAAAAAAAAAgNM3AAABAAAcAAAAACAAqQAAABYwAAAAAAAA
AIDTNwAAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA0zcAAAEAABgAAAAAIACZAAAAADAAAAAA
AAAAgNM3AAABAAAcAAAAACAAqQAAABYwAAAAAAAAAIDTNwAAAQAAGAAAAAAgAKkAAAAAMAAA
AAAAAACA0zcAAAEAABgAAAAAIACZAAAAADAAAAAAAAAAgNM3AAABAAAcAAAAACAAqQAAABYw
AAAAAAAAAIDTNwAAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA0zcAAAEAABgAAAAAIACZAAAA
ADAAAAAAAAAAgNM3AAABAAAcAAAAACAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA
CCAYMAIAAAAAAACA0zcAAAAAAFAAAAAAgACYAAggGDADAAAAAAAAgNM3AAAAAAAAAAAAAAAA
mAAIIBgwBAAAAAAAAIDTNwAAAAAAAAAAAAAAAJgACCAYMAUAAAAAAACA0zcAAAAAAFAAAAAA
gACYAAggGDAGAAAAAAAAgNM3AAAAAAAAAAAAAAAAmAAIIBgwBwAAAAAAAIDTNwAAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgNM3AAAAAABQ
AAAAAIAAKAAAAAMwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA7UQAAAAA
AFAAAAAAgACYAAAAADAAAAAAAAAAgO1EAAAAAAAAAAAAAAAAqQAAABYwAAAAAAAAAIDtRAAA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA7UQAAAEAABgAAAAAIACZAAAAADAAAAAAAAAAgO1E
AAABAAAcAAAAACAAqQAAABYwAAAAAAAAAIDtRAAAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA
7UQAAAEAABgAAAAAAACpAAAAADAAAAAAAAAAgO1EAAABAAAYAAAAACAAmQAAAAAwAAAAAAAA
AIDtRAAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACA7UQAAAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgO1EAAABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIDtRAAAAQAAHAAAAAAgACgAAAADMAAA
AAAAAACAbjYAAAAAAPgAAAAAgACYAAAAADAAAAAAAAAAgO1LAAAAAABQAAAAAIAAKAAAAAMw
AAAAAAAAAIBuNgAAAAAAAAAAAAAAACgAAAADMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIBATAAAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgEBMAAAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAIBATAAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAQEwAAAAAAFAAAAAA
gACYAAAAADAAAAAAAAAAgEBMAAAAAABQAAAAAIAAqQAAABYwAAAAAAAAAIBATAAAAQAAGAAA
AAAgAKkAAAAAMAAAAAAAAACAQEwAAAEAABgAAAAAAACpAAAAADAAAAAAAAAAgEBMAAABAAAY
AAAAAAAAqQAAAAAwAAAAAAAAAIBATAAAAQAAGAAAAAAAAKkAAAAAMAAAAAAAAACAQEwAAAEA
ABgAAAAAIACZAAAAADAAAAAAAAAAgEBMAAABAAAcAAAAACAAqQAAABYwAAAAAAAAAIBATAAA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAQEwAAAEAABgAAAAAAACpAAAAADAAAAAAAAAAgEBM
AAABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIBATAAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACA
QEwAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgEBMAAABAAAYAAAAACAAmQAAAAAwAAAAAAAA
AIBATAAAAQAAHAAAAAAgAJgAAAAAMAAAAAAAAACAQEwAAAAAAPgAAAAAgACYAAAAADAAAAAA
AAAAgEBMAAAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIBATAAAAAAAUAAAAACAAKkAAAAWMAAA
AAAAAACAQEwAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgEBMAAABAAAYAAAAACAAmQAAAAAw
AAAAAAAAAIBATAAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAQEwAAAEAABgAAAAAIACpAAAA
ADAAAAAAAAAAgEBMAAABAAAAAAAAAKAAmQAAAAAwAAAAAAAAAIBATAAAAQAAHAAAAAAgAKkA
AAAWMAAAAAAAAACAQEwAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgEBMAAABAAAYAAAAACAA
mQAAAAAwAAAAAAAAAIBATAAAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAQEwAAAEAABgAAAAA
IACpAAAAADAAAAAAAAAAgEBMAAABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIBATAAAAQAAHAAA
AAAgAKkAAAAWMAAAAAAAAACAQEwAAAEAABgAAAAAIACpAAAAADAAAAAAAAAAgEBMAAABAAAY
AAAAAAAAqQAAAAAwAAAAAAAAAIBATAAAAQAAAAAAAACAAKkAAAAAMAAAAAAAAACAQEwAAAEA
ABgAAAAAIACZAAAAADAAAAAAAAAAgEBMAAABAAAcAAAAACAAmAAAAAAwAAAAAAAAAIBATAAA
AAAA+AAAAACAABgAAAACMAAAAAAAAACA/hgAAAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgNRo
AAAAAABQAAAAAIAAGAAAAAIwAAAAAAAAAID+GAAAAAAAAAAAAAAAABgAAAACMAAAAAAAAACA
/hgAAAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgM9qAAAAAABQAAAAAIAAmAAAAAAwAAAAAAAA
AIDPagAAAAAAAAAAAACAABgAAAACMAAAAAAAAACA/hgAAAAAAFAAAAAAgACYAAAAADAAAAAA
AAAAgPpsAAAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAID6bAAAAAAAUAAAAACAAJgAAAAAMAAA
AAAAAACA+mwAAAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgPpsAAAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAID6bAAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAAgAAAABMAAA
AAAAAACAAAAAgAAAAAAAAAAACACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAUAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAACAAJgA
AAAAMAAAAAAAAACAAAAAgAAAABAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgAAAAIAAAAAQAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAEAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
ABAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAGAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AFAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgAAA
AIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA
AAAAgAAAABAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAA
AAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAEAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAGAAAAAIwAAAAAAAAAIAAAACA
AAAAAAAAAACAABgAAAACMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAUAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAaAAAAACAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAACAAAgAAAABMAAAAAAAAACAAAAAgAAAAAAAAAAAgAAYAAAA
AjAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAGAAAAAIwAAAAAAAAAIAAAACAAAAAAAAA
AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAggGDAAAAAAAAAAgAAAAIAAAAAA
AAAAAIAAmAAIIBgwAAAAAAAAAIAAAACAAAAAUAAAAACAAJgACCAYMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAggGDAAAAAAAAAAgAAAAIAAAABQAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAUAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAAYAAAAAjAAAAAAAAAAgAAA
AIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAUAAAAACAABgAAAACMAAAAAAAAACA
AAAAgAAAABAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAQAAAAAAAACAAAAAEwAAAAAAAA
AIAAAACAAAAAEAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAXMAAA
AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAUAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAFAAAAAAgACYAAAA
ADAAAAAAAAAAgAAAAIAAAABQAAAAAIAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAA
IACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA
ABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA
AAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAA
AIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAA
AAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAw
AAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAA
FjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAA
IACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA
ABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACA
AAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAA
AIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAA
AAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAw
AAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAA
ADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkA
AAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAA
IACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA
ABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA
AAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAA
AIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAA
AAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAw
AAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAA
FjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAA
IACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA
ABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACA
AAAAgAEAABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAA
AIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAA
AAAAAACAAAAAgAEAABwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAw
AAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAA
ADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
mQAAAAAwAAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAAAAAgAEAABgAAAAA
IACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAY
AAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAAAAAgAEA
ABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAA
AIABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACA
AAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAA
AIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgAAAAIABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAWMAAA
AAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAw
AAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAA
ADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAHAAAAAAgAKkA
AAAWMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAA
IACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAAHAAA
AAAgAKkAAAAWMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA
ABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAwAAAAAAAAAIAAAACA
AQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA
AAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAwAAAAAAAA
AIAAAACAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAA
AAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAw
AAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACZAAAA
ADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAABYwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAA
IACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAABYwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA
ABgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAABYwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA
AAAAgAEAABgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAABYwAAAAAAAA
AIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAA
AAAAAACAAAAAgAEAABgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAABYw
AAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAA
ADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAA
IACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA
ABwAAAAAIACpAAAAFjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACA
AAAAgAEAABwAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAwAAAAAAAA
AIAAAACAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAA
AAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAmQAAAAAw
AAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAWMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAA
ADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
mQAAAAAwAAAAAAAAAIAAAACAAQAAHAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAA
IACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAABYwAAAAAAAAAIAAAACAAQAAGAAA
AAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAY
AAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEA
ABgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAABYwAAAAAAAAAIAAAACA
AQAAGAAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAA
AIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAAAAAAAACA
AAAAgAEAABgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAAAcAAAAACAAqQAAAAAwAAAAAAAA
AIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAAFjAAAAAA
AAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkAAAAAMAAA
AAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAw
AAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAAIACpAAAA
FjAAAAAAAAAAgAAAAIABAAAYAAAAACAAqQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAKkA
AAAAMAAAAAAAAACAAAAAgAEAABgAAAAAIACpAAAAADAAAAAAAAAAgAAAAIABAAAYAAAAACAA
qQAAAAAwAAAAAAAAAIAAAACAAQAAGAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAABwAAAAA
IACYAAAAADAAAAAAAAAAgAAAAIAAAAD4AAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAA07ATAAAAAAAAAAAAEAAAABAAAAAAAAAGAFmwcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAALAAAAGgAAABoAAAAaAAAAHAAAABwAAAAcAAAALAAAACwAAAAsAAAA
LwAAAAAGAAAPCwAAlgwAAAQOAADPEgAAnhsAAEEgAADQIQAAliIAAColAACOJwAAvCgAAK4p
AAAYLQAAkzAAAJ4xAABQNwAAgTkAAAY8AAD4PAAAtT0AAKI/AACKRAAAI00AAB1RAAA1VAAA
o1YAAFZaAADiXQAA3F8AANJiAAANagAAeXIAAFl7AAC9fgAAIIwAALqPAACDlQAAgJsAAP6f
AACqpwAASbMAABvBAACsyQAAGNgAAPncAABV4gAAhOIAAHIAAAB1AAAAdgAAAHcAAAB5AAAA
fQAAAH4AAAB/AAAAgAAAAIIAAACDAAAAhAAAAIUAAACHAAAAiAAAAIkAAACMAAAAjwAAAJEA
AACTAAAAlAAAAJUAAACXAAAAoAAAAKIAAACkAAAApQAAAKYAAACnAAAAqQAAAKsAAACtAAAA
rwAAALEAAACyAAAAtAAAALUAAAC2AAAAuAAAALkAAAC7AAAAvgAAAMEAAADCAAAAxQAAANkA
AAD2AAAAAAYAALgPAADoFgAADBoAANIaAAAyJAAAHCsAAM42AAAGNwAAWTcAACk5AACoOQAA
TzwAAEJCAAA9RQAA9UUAAOpHAABbSQAA1kkAAIZKAABDSwAAFUwAAM1OAAA0VAAALl8AABxi
AAAHaAAAYGsAABlzAAAziAAAeJsAAGWgAACuqAAAz6oAALy0AAAqugAALsoAADzOAADh1gAA
BNoAABLaAAA52gAAZtoAAJXaAADD2gAA89oAACHbAABH2wAAcNsAAJ3bAADH2wAA8tsAACDc
AABR3AAAgdwAALzcAAD43AAACt0AADndAABo3QAAlt0AAMzdAAAJ3gAAN94AAFzeAACq3gAA
1d4AAOXeAAAq3wAAbN8AAKLfAAAG4AAASeAAAF7gAACa4AAA6uAAAAfhAABF4QAAcuEAAIDh
AACv4QAA3OEAAOrhAAAe4gAAUeIAAGriAACE4gAAcwAAAHgAAAB6AAAAewAAAHwAAACBAAAA
hgAAAIoAAACLAAAAjQAAAI4AAACQAAAAkgAAAJYAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0A
AACeAAAAnwAAAKEAAACjAAAAqAAAAKoAAACsAAAArgAAALAAAACzAAAAtwAAALoAAAC8AAAA
vQAAAL8AAADAAAAAwwAAAMQAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4A
AADPAAAA0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2gAAANsAAADcAAAA
3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoA
AADrAAAA7AAAAO0AAADuAAAA7wAAAPAAAADxAAAA8gAAAPMAAAD0AAAA9QAAAPcAAAAABgAA
g+IAAHQAAAAhAwAAUQMAAG0DAAB9AwAAqAMAAL8DAADMAwAA7gMAAPwDAAAXBAAAQQQAAFcE
AABtBAAAlQQAAKkEAADtBAAAHQUAADkFAABJBQAAcQUAAIUFAACTBQAAuQUAAMsFAADcBQAA
BQYAABoGAAAWCQAAQgkAAH0JAACzQgAA2EIAAOVCAAAIRQAAI0UAAClFAACr0AAAwtAAAMTQ
AACE2gAAE1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWM
E1gU/xWME1gU/xWME1gU/xWME1gU/xWMEwwU/5WAAAAAAAcAAAALAAAAEgAAABQAAAAdAAAA
JAAAACcAAAAvAAAAEyGVDBMhFP+VgBMhFP8VgAEAAAD//////////wAAAAAAAAAAAAAAAA8A
APCYAAAAAAAG8BgAAAACCAAAAgAAAAYAAAABAAAAAQAAAAcAAAAvAAHwWAAAADIAB/AkAAAA
AwR2loeqsTY0JxR1t2w4PURG/wBnAwAAAAAAAP////8AAAAAYgAH8CQAAAAGBoc5NDV1LxJ2
W1oL0GpTZ/L/AJAKAAAAAAAA/////wAAAABAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAADwAC
8J4AAAAQAAjwCAAAAAEAAAAGBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAB
gP//AYD//wIACvAIAAAAAAQAAAUAAAAPAATwTgAAABIACvAIAAAAAQQAAAAOAABzAAvwKgAA
AIEBALj/AIMBAAAAAL8BEAAQAMABAQAACMsBAAAAAP8BAAAIAAECAgAACAAAEfAEAAAAAQAA
AITaAAD//z4AAAARAE4AdQBtAGIAZQByAGUAZAAgAFMAdAB5AGwAZQBzACAAMQARAE4AdQBt
AGIAZQByAGUAZAAgAFMAdAB5AGwAZQBzACAAMgARAE4AdQBtAGIAZQByAGUAZAAgAFMAdAB5
AGwAZQBzACAAMwARAE4AdQBtAGIAZQByAGUAZAAgAFMAdAB5AGwAZQBzACAANAARAE4AdQBt
AGIAZQByAGUAZAAgAFMAdAB5AGwAZQBzACAANQARAE4AdQBtAGIAZQByAGUAZAAgAFMAdAB5
AGwAZQBzACAANgASAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAAxABIAVABh
AGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADIAEgBUAGEAYgBsAGUAIABQAHIAbwBw
AGUAcgB0AGkAZQBzACAAMwASAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA0
ABIAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADUAEgBUAGEAYgBsAGUAIABQ
AHIAbwBwAGUAcgB0AGkAZQBzACAANgASAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBl
AHMAIAA3ABIAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADgAEgBUAGEAYgBs
AGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAAOQATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQBy
AHQAaQBlAHMAIAAxADEAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAAMwA5
ABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADQAMAATAFQAYQBiAGwAZQAg
AFAAcgBvAHAAZQByAHQAaQBlAHMAIAA0ADEAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0
AGkAZQBzACAANAAyABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADQAMwAT
AFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA0ADQAEwBUAGEAYgBsAGUAIABQ
AHIAbwBwAGUAcgB0AGkAZQBzACAANAA1ABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABp
AGUAcwAgADQANgATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA0ADcAEwBU
AGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAANAA4ABMAVABhAGIAbABlACAAUABy
AG8AcABlAHIAdABpAGUAcwAgADQAOQATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBl
AHMAIAA1ADAAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAANQAxABMAVABh
AGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADUAMgATAFQAYQBiAGwAZQAgAFAAcgBv
AHAAZQByAHQAaQBlAHMAIAA1ADMAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBz
ACAANQA0ABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADUANQATAFQAYQBi
AGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA1ADYAEwBUAGEAYgBsAGUAIABQAHIAbwBw
AGUAcgB0AGkAZQBzACAANQA3ABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAg
ADUAOAATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA1ADkAEwBUAGEAYgBs
AGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAANgAwABMAVABhAGIAbABlACAAUAByAG8AcABl
AHIAdABpAGUAcwAgADYAMQATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA2
ADIAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAANgAzABMAVABhAGIAbABl
ACAAUAByAG8AcABlAHIAdABpAGUAcwAgADYANAATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQBy
AHQAaQBlAHMAIAA2ADUAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAANgA2
ABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADYANwATAFQAYQBiAGwAZQAg
AFAAcgBvAHAAZQByAHQAaQBlAHMAIAA2ADgAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0
AGkAZQBzACAANgA5ABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADcAMAAT
AFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA3ADEAEwBUAGEAYgBsAGUAIABQ
AHIAbwBwAGUAcgB0AGkAZQBzACAANwAyABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABp
AGUAcwAgADcAMwATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA3ADQAEwBU
AGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAANwA1ABMAVABhAGIAbABlACAAUABy
AG8AcABlAHIAdABpAGUAcwAgADcANgATAFQAYQBiAGwAZQAgAFAAcgBvAHAAZQByAHQAaQBl
AHMAIAA3ADcAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBzACAANwA4ABMAVABh
AGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADcAOQATAFQAYQBiAGwAZQAgAFAAcgBv
AHAAZQByAHQAaQBlAHMAIAA4ADAAEwBUAGEAYgBsAGUAIABQAHIAbwBwAGUAcgB0AGkAZQBz
ACAAOAAxABMAVABhAGIAbABlACAAUAByAG8AcABlAHIAdABpAGUAcwAgADgAMgATAFQAYQBi
AGwAZQAgAFAAcgBvAHAAZQByAHQAaQBlAHMAIAA4ADMAEwBUAGEAYgBsAGUAIABQAHIAbwBw
AGUAcgB0AGkAZQBzACAAOAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHY4AAA+PQAAlT0A
APY9AABTPgAA6z8AAJBAAACfQQAA10EAAGVCAADa0QAABdIAABPSAAA60gAAZ9IAAJbSAADE
0gAA9NIAACLTAABI0wAAcdMAAJ7TAADI0wAA89MAACHUAABS1AAAgtQAAL3UAAD51AAAC9UA
ADrVAABp1QAAl9UAAM3VAAAK1gAAONYAAF3WAACr1gAA1tYAAObWAAAr1wAAbdcAAKPXAAAH
2AAAStgAAF/YAACb2AAA69gAAAjZAABG2QAAc9kAAIHZAACw2QAA3dkAAOvZAAAf2gAAhdoA
AAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN
AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAA
ABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAo
AAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAA
ADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAPj0AAJU9AAD2PQAAUz4AAOs/AACQQAAAn0EAANdBAABlQgAAh0IAAAXSAAAT0gAAOtIA
AGfSAACW0gAAxNIAAPTSAAAi0wAASNMAAHHTAACe0wAAyNMAAPPTAAAh1AAAUtQAAILUAAC9
1AAA+dQAAAvVAAA61QAAadUAAJfVAADN1QAACtYAADjWAABd1gAAq9YAANbWAADm1gAAK9cA
AG3XAACj1wAAB9gAAErYAABf2AAAm9gAAOvYAAAI2QAARtkAAHPZAACB2QAAsNkAAN3ZAADr
2QAAH9oAAFLaAACF2gAA//8BAAAABgDOFy8FAAABAMyD5QP62QAAhdoAAAAAAAABAAPaAACF
2gAAAAAAAAEAAAA4AAAAAQAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6
c21hcnR0YWdzBIB0aW1lAIAMAAABAQAAAAMAAAABgDAEgEhvdXIGgE1pbnV0ZQEAAgAAAAEA
AAAAAAAAAgAAAAAAAAAAAAAADQMAABYDAAAGBAAADAQAALMEAAC6BAAA4QQAAOsEAABCBQAA
RwUAAIwFAACRBQAA/AYAAAAHAACTBwAAlwcAALEJAADyCQAA8wkAADEKAAAyCgAAhgoAAIcK
AADgCgAA4QoAAB4LAADoDgAA7A4AAFwPAABgDwAAkA8AAJQPAABFEAAASRAAAIgQAACMEAAA
1hAAANoQAADoEAAA7BAAAE4RAABSEQAAxxEAAMsRAABUEgAAWBIAAK0SAACxEgAA4xIAAOcS
AABLEwAATxMAACwUAAAwFAAAeRQAAH0UAAAwFQAAQBUAANgVAADaFQAAGhoAACQaAAC6GgAA
wBoAAMUaAADOGgAAThsAAFIbAAC0HAAAvhwAAGUfAABuHwAAfh8AAI0fAADiHwAA7x8AADAg
AAA5IAAAUSAAAGAgAABuIAAAhiAAAIoiAACTIgAAvSIAAMwiAADOIgAA6CIAABwjAAAoIwAA
KSMAADsjAACbIwAAuiMAAPkjAAAhJAAA8CUAAPQlAAA8JgAAaCYAAJEmAAC9JgAA+yYAAP8m
AACsKAAArigAALcoAAC7KAAAVCkAAF0pAAC4KQAAvCkAAFcrAABbKwAAGCwAAB4sAADOLgAA
3S4AAN4uAADyLgAA8y4AAAUvAAAGLwAAEy8AABQvAAAhLwAAhi8AAI0vAACOLwAAki8AALEv
AAC1LwAAnzAAAKMwAADTMAAA3DAAAAExAAAWMQAAKTEAAD4xAACKMQAAlDEAAKgxAADKMQAA
UjIAAGgyAACQMgAAvjIAAO0yAAAQMwAAYzMAAJYzAAAhNQAAKjUAAGM1AABuNQAAdjUAAH81
AACsNQAAtTUAAMQ1AADNNQAA3DUAAOU1AAAANgAACTYAACY2AAAxNgAAbTYAAHg2AAAYNwAA
HDcAAHY4AAB7OAAADDkAABE5AAAaOgAAIzoAADU6AABAOgAAtDoAALg6AADHOwAAyzsAACY9
AAA7PQAAlT0AAJo9AAD2PQAA+T0AAFM+AABXPgAAET8AABM/AABDPwAARz8AAGg/AABqPwAA
kD8AAKY/AACzPwAAxD8AAB1BAAAlQQAA10EAANpBAABHQwAASkMAALhDAAC9QwAAwkYAAMZG
AADJRgAAy0YAAMxHAADORwAAl0gAAJlIAAAbSQAAHUkAAJRJAAC0SQAAEEoAAClKAAB4SgAA
ekoAAKhKAACwSgAAtUoAAMZKAAALTQAAH00AACBNAAAoTQAAKU4AACtOAACRTgAAo04AAA1R
AAASUQAALlEAADNRAADRUQAA1lEAACFTAAApUwAAb1MAAHdTAAATVAAAG1QAAFtVAABnVQAA
2lUAAOJVAAAvVwAAM1cAADdXAAA7VwAAiVcAAJNXAADJVwAA2lcAAOBXAADwVwAAdVkAAH1Z
AAAtWgAAMVoAAMVaAADJWgAAulsAANdbAACJXAAAjVwAAE1dAABRXQAAUl0AAHBdAAB1XQAA
lV0AADBeAAA4XgAAKF8AACxfAABbXwAAaF8AAGxfAAB7XwAAxF8AANhfAAA5YAAAPWAAAElg
AABNYAAACGEAABRhAABDYQAARWEAAEdhAABKYQAAg2EAAIxhAAC9YQAAwWEAAK1kAAC2ZAAA
ZmUAAHJlAADNZwAA0mcAAHJoAAB9aAAAOGkAADxpAADQaQAA1GkAANhpAADbaQAAEmsAABdr
AAAebAAAMGwAAHZsAACCbAAAumwAAL5sAABJbQAATW0AAHBtAAB0bQAAtm0AALptAACfbgAA
qG4AAK1uAAC3bgAAPm8AAEJvAAC0bwAAuG8AABlwAAAdcAAAB3EAAAtxAABUcQAAWHEAABdy
AAAjcgAAlnMAAJpzAACycwAAtnMAAAx0AAAQdAAAfnQAAIJ0AACEdAAAtnQAALt0AADndAAA
/HQAABN1AABVdQAAWXUAAIt1AACPdQAA8XUAAPV1AAD2dQAAInYAACd2AABBdgAAVXcAAFl3
AADzeAAA93gAAJJ7AACWewAA5HwAAOh8AAD9fAAAB30AAFR9AABYfQAAln4AAJp+AACgfgAA
uX4AAPt+AAD/fgAARYAAAEmAAACXgAAAm4AAAHqBAAB+gQAA3IIAAOCCAACUhQAAmIUAAGKH
AABmhwAAqYgAAK2IAAC6iAAAvogAAE6JAABUiQAAWIkAAGCJAADFiQAAzYkAAOeJAADriQAA
XIoAAGCKAAB9igAAhYoAANeKAADbigAAMYsAADWLAAARjQAAFY0AAF6OAABijgAAg44AAIeO
AACmjgAAqo4AAAWPAAAMjwAAHo8AACKPAAB/jwAAiY8AAM6QAADakAAAOJEAAEWRAABWkQAA
XJEAAJ+RAACukQAAvpEAAM6RAADdkQAA7JEAAAiSAAAPkgAA0ZIAANWSAACBkwAAhJMAAIaT
AACSkwAAoZMAAKSTAACmkwAArZMAAL2TAADAkwAAwpMAAMiTAADjkwAA5pMAAOiTAADxkwAA
BJQAAAeUAAAJlAAAE5QAAC2UAAAwlAAAMpQAADuUAAD+lAAAApUAANKVAADWlQAA+pUAAP6V
AAAGlwAAEpcAAEaXAABTlwAAbJcAAHqXAAB9lwAAhpcAAKCXAACqlwAAxJcAANKXAADVlwAA
4pcAAPqXAAAImAAADJgAABWYAAA1mAAAP5gAAGaYAAB1mAAAkJgAAJyYAAC+mAAAypgAANGY
AADemAAAAZkAAA+ZAAATmQAAIpkAAD+ZAABPmQAAc5kAAICZAACfmQAArZkAALCZAAC5mQAA
5pkAAPCZAAAZmgAALJoAAGCaAABomgAA1poAANqaAACYmwAAnJsAAKufAACunwAA6KAAAPSg
AAD2oAAAC6EAAA2hAAAcoQAAHqEAACqhAAAtoQAAPKEAAD+hAABMoQAATqEAAGOhAABloQAA
caEAAHShAACDoQAAhaEAAJGhAACUoQAAo6EAAN+hAADjoQAA9qEAAPqhAAAfowAAKKMAAKij
AACvowAAnacAAK+nAACzpwAAxqcAAFSpAABhqQAAY6kAAG+pAAByqQAAf6kAAJCpAACcqQAA
16kAAPGpAAAAqgAADKoAAA+qAAAcqgAALaoAADmqAABQqgAAa6oAAHyqAACOqgAAN6sAAECr
AAAzrQAAOq0AADytAABIrQAASq0AAFetAABorQAAdK0AAK+tAADJrQAA2q0AAOatAADprQAA
9q0AAAeuAAATrgAAKq4AADyuAABhrgAAfK4AAJiwAACisAAAvLEAAMaxAADXsQAA3rEAAOWx
AAD2sQAA+LEAAASyAAAdsgAAKbIAAC6yAAAxsgAAkLIAAJqyAAC0sgAAwLIAAMSyAADQsgAA
ObMAAEGzAADTswAA2rMAAA21AAAVtQAA+rUAAAK2AAButgAAd7YAAMi3AADStwAAK7kAAC+5
AACYuQAAnLkAAB+6AAAnugAATboAAE+6AACsvAAAsLwAANfAAADbwAAAcMkAAHTJAAAY0AAA
HtAAADDQAAA10AAAONYAAD/WAABd1gAAZNYAAKvWAACy1gAA5tYAAO7WAAAr1wAAM9cAAF7X
AABk1wAAbdcAAHXXAACj1wAAq9cAAAfYAAAP2AAAPNgAAELYAACB2QAAjtkAALDZAAC92QAA
69kAAPjZAAAf2gAALNoAAFTaAACA2gAAgdoAAIXaAAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcABQAHAAUABwAFAAcABQAHAAUABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABsABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA
BwAcAAcABwACAAcAAAAAAMQBAADWAQAAHQIAACwCAACxCQAAHgsAAGENAABnDQAAIw4AACUO
AACoEwAAuxMAAB4VAAAfFQAANRYAADcWAAD/GAAAARkAAC8aAAA0GgAAhx8AAI0fAADpHwAA
7x8AAFogAABgIAAAdyAAAIAgAACKIgAAkyIAANciAADiIgAAJSMAACgjAAA+IwAAVCMAAKQj
AACvIwAAAiQAAA0kAABFJgAAUCYAAJomAACsJgAAuygAAMAoAAC4KQAAvykAACIvAAA6LwAA
Zy8AAGsvAAApMQAALDEAACsyAAAtMgAAWzIAAGgyAACNMgAAmTIAAMUyAADpMgAA6jIAAPEy
AABVMwAAWjMAAOUzAADqMwAACDQAAAw0AAApNAAALzQAADs0AABENAAAUDQAAFU0AABvNAAA
czQAALQ0AAC5NAAA1jQAANo0AAAhNQAAIjUAAG41AABzNQAAjDUAAJA1AACsNQAArTUAAM01
AADZNQAAADYAAAE2AAAfNgAAIzYAAHg2AAB6NgAAfTgAAIc4AADfPAAA6TwAAGk+AAB2PgAA
CT8AABA/AACZPwAApj8AAM1GAADXRgAAC0gAABVIAACYSQAArkkAABNKAAAjSgAAwEoAAMZK
AAACSwAADEsAABBNAAAfTQAAJU4AAClOAACaTgAAo04AAM5RAADkUQAAT1MAAFBTAAA/VwAA
QVcAANxYAADeWAAAw1sAAM5bAABfXQAAal0AADpfAABQXwAA0V8AANhfAAALYQAAFGEAAPNl
AAD2ZQAAi3IAAJhyAAB+dAAAjXQAAP91AAAKdgAAfnYAAIR2AAAUfwAAHn8AAGN/AABnfwAA
mYcAAJyHAAChiAAArYgAAOeJAADviQAAz4wAANiMAAAAjwAADI8AAM6QAADSkAAAJJEAACmR
AAA/kQAARZEAAFaRAABckQAAqJEAAK6RAADIkQAAzpEAAOaRAADskQAAP5MAAEeTAACJkwAA
k5MAAAaXAAASlwAATZcAAFOXAABslwAAb5cAAHiXAAB6lwAAfZcAAIaXAACglwAAqpcAAMSX
AADIlwAA0JcAANKXAADclwAA4pcAAPqXAAD9lwAABpgAAAiYAAAMmAAAFZgAADWYAAA/mAAA
b5gAAHWYAACQmAAAnJgAANiYAADemAAAAZkAAASZAAANmQAAD5kAAByZAAAimQAASZkAAE+Z
AAB6mQAAgJkAAJ+ZAACimQAAq5kAAK2ZAACwmQAAuZkAAOaZAADwmQAAJpoAACyaAADPmgAA
8poAAJKbAAClmwAAmp8AAJ+fAAAFoQAAC6EAABahAAAcoQAANqEAADyhAABdoQAAY6EAAH2h
AACDoQAAnaEAAKOhAACmpwAAr6cAAHmpAAB/qQAAkKkAAJSpAADgqQAA66kAABaqAAAcqgAA
LaoAADmqAABZqgAAZaoAAIiqAACOqgAAMa0AADKtAABRrQAAV60AAGitAABsrQAAuK0AAMOt
AADwrQAA9q0AAAeuAAATrgAANq4AADyuAABqrgAAdq4AAFCwAABasAAAXLAAAIewAADVsQAA
1rEAAOWxAADtsQAACbIAABSyAAAusgAAMbIAAAq1AAAVtQAA8LgAAPO4AAAxvAAAWbwAAJjE
AAChxAAAd80AAILNAABU2gAAgNoAAIHaAACF2gAABwAzAAcAMwAHAAUABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHAAcAAgAHAAAAAACwGQAA3BkAAN0ZAADeGQAAChoAAAoaAAAnGgAAJxoAAEQaAABEGgAA
JR0AACYdAAAoHQAAKB0AACkdAAApHQAAKh0AACodAAA1HQAAPh0AAFYdAAB/HQAA+x8AAPsf
AAAEIAAADSAAAA4gAAAOIAAAJiEAACYhAAAnIQAAJyEAACghAAAoIQAAKSEAACkhAAAqIQAA
LiEAADkhAAA5IQAARyEAAEghAAAcJQAAICUAAEYlAABHJQAA10IAANhCAAAiRQAAI0UAAEJF
AABDRQAAl0wAAJhMAACuTAAAr0wAABlPAAAaTwAAr14AAK9eAABQZQAAUWUAAKJlAACiZQAA
5G8AAORvAAD1bwAA9W8AAIp2AACKdgAA83YAAPd2AABZkQAAXJEAAF2RAABdkQAAXpEAAF6R
AABfkQAAX5EAAGCRAABgkQAAYZEAAGGRAABikQAAYpEAAGORAABjkQAAZJEAAGSRAABlkQAA
ZZEAAMWTAADIkwAAyZMAAMmTAADKkwAAypMAAMuTAADLkwAAzJMAAMyTAADNkwAAzZMAAM6T
AADOkwAAz5MAAM+TAADQkwAA0JMAANGTAADRkwAAeJcAAHqXAADQlwAA0pcAAAaYAAAImAAA
DZkAAA+ZAACrmQAArZkAAE26AABQugAAUdoAAFTaAACA2gAAgdoAAIHaAACF2gAAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA
AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA
AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA
BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAcABwACAAQABwAAAAAAVNoAAIDaAACB2gAA
hdoAAAcABwACAAcA//8IAAAAEgBQAHIAZQBmAGUAcgByAGUAZAAgAEMAdQBzAHQAbwBtAGUA
cgAAAAwAUgBvAHkAIABXAGkAbABsAGkAYQBtAHMAAAAOAFQAaABvAG0AYQBzACAATQBjAEcA
bAB5AG4AbgAAAAgARQBkACAAUwBoAGEAeQBhAAAAIQACAAAAAgAAAP8P/w//D/8P/w//D/8P
/w//DwAAAwAAAAMAAAD/D/8P/w//D/8P/w//D/8P/w8AAAQAAAAEAAAA/w//D/8P/w//D/8P
/w//D/8PAADKSdECOAWUEv8P/w//D/8P/w//D/8P/w//DxAATVNdBgMAAAD/D/8P/w//D/8P
/w//D/8P/w8AACMf4QkDAAAA/w//D/8P/w//D/8P/w//D/8PAAA+GlYOcgfQff8P/w//D/8P
/w//D/8P/w//DwAAQxkaDwMAAAD/D/8P/w//D/8P/w//D/8P/w8AAJViBhAWAw6u/w//D/8P
/w//D/8P/w//D/8PEACfMskQJDdcYAEAAgADAP8P/w//D/8P/w//DwAAz2oCHk4ODH7/D/8P
/w//D/8P/w//D/8P/w8AALhiriSgM/D//w//D/8P/w//D/8P/w//D/8PEADeWMApnGWIyhgA
/w//D/8P/w//D/8P/w//DxAAFEBEKurWHmv/D/8P/w//D/8P/w//D/8P/w8AAC0wISxyB9B9
/w//D/8P/w//D/8P/w//D/8PAAA7RAstAwAAAP8P/w//D/8P/w//D/8P/w//DwAATRZ1Ldwi
xp3/D/8P/w//D/8P/w//D/8P/w8AAAIYHC4OQYKg/w//D/8P/w//D/8P/w//D/8PAABLMw0v
XOUWhP8P/w//D/8P/w//D/8P/w//DwAAeFbUMZQuAhr/D/8P/w//D/8P/w//D/8P/w8QAAUD
BjRkxhaX/w//D/8P/w//D/8P/w//D/8PAABeIsI8JDdcYP8P/w//D/8P/w//D/8P/w//DwAA
EUx3QAMAAAD/D/8P/w//D/8P/w//D/8P/w8AAD48xkBu3hDy/w//D/8P/w//D/8P/w//D/8P
EAD4OxFC8nJOyf8P/w//D/8P/w//D/8P/w//DxAAk3ZlSTwNFs8ZAP8P/w//D/8P/w//D/8P
/w8QANpoHlPchCxv/w//D/8P/w//D/8P/w//D/8PEABmPlZTdgkmVf8P/w//D/8P/w//D/8P
/w//DxAA2XrtVrbknEX/D/8P/w//D/8P/w//D/8P/w8QAJY7wG3cIsad/w//D/8P/w//D/8P
/w//D/8PEAABc/FtcgfQff8P/w//D/8P/w//D/8P/w//DwAAaWuKdnIH0H3/D/8P/w//D/8P
/w//D/8P/w8AAB12cX8DAAAA/w//D/8P/w//D/8P/w//D/8PAAABAAAAAAACAAAAAAAAAAAC
AAAAAAAAAAAAEAAAD4TQAhGEmP5ehNACYISY/gMAIAAAAC4AAQAAAAAAAgQAAAAAAAAAAgAA
AAAAAAAAABAAAA+EoAURhJj+XoSgBWCEmP4FACAAAAAuAAEALgABAAAABAACAAAAAAAAAAAC
AAAAAAAAAAAAEAAAD4RwCBGEmP5ehHAIYISY/gMAIAACACkAAQAAABcAAAAAAAAAAAAAAgAA
AAAAAAAAFBAAAA+EQAsRhJj+XoRAC2CEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAA
FwAAAAAAAAAAAAACAAAAAAAAAAAUEAAAD4QQDhGEmP5ehBAOYISY/k9KBgBRSgYAQ0oSAFBK
BgBDShIAAQAiIAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhOAQEYSY/l6E4BBghJj+
T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+E
sBMRhJj+XoSwE2CEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAAC
AAAAAAAAAAAUEAAAD4SAFhGEmP5ehIAWYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEA
AAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhFAZEYSY/l6EUBlghJj+T0oGAFFKBgBDShIA
UEoGAENKEgABACIgAQAAAAAAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+E0AIRhJj+XoTQAmCE
mP4DACAAAAAuAAEAAAAAAAIEAAAAAAAAAAIAAAAAAAAAAAAQAAAPhKAFEYSY/l6EoAVghJj+
BQAgAAAALgABAC4AAQAAAAQAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+EcAgRhJj+XoRwCGCE
mP4DACAAAgApAAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhEALEYSY/l6EQAtghJj+
T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+E
EA4RhJj+XoQQDmCEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAAC
AAAAAAAAAAAUEAAAD4TgEBGEmP5ehOAQYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEA
AAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhLATEYSY/l6EsBNghJj+T0oGAFFKBgBDShIA
UEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EgBYRhJj+XoSAFmCE
mP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAAAAAAAAAUEAAA
D4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAD/AAAAAAAAAAAA
AAIAAAAAAAAAAAAQAAAPhAAAEYQAAF6EAABghAAAAAABAAAA/wAAAAAAAAAAAAACAAAAAAAA
AAAAEAAAD4QAABGEAABehAAAYIQAAAAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABAAAA+E
AAARhAAAXoQAAGCEAAAAAAEAAAD/AAAAAAAAAAAAAAIAAAAAAAAAAAAQAAAPhAAAEYQAAF6E
AABghAAAAAABAAAA/wAAAAAAAAAAAAACAAAAAAAAAAAAEAAAD4QAABGEAABehAAAYIQAAAAA
AQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABAAAA+EAAARhAAAXoQAAGCEAAAAAAEAAAD/AAAA
AAAAAAAAAAIAAAAAAAAAAAAQAAAPhAAAEYQAAF6EAABghAAAAAABAAAA/wAAAAAAAAAAAAAC
AAAAAAAAAAAAEAAAD4QAABGEAABehAAAYIQAAAAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAA
ABAAAA+EAAARhAAAXoQAAGCEAAAAAAEAAAAXAAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhNAC
EYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAAASAAQAA
AAAAAAAAAAAAAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAAC
AAEALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhg
hEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhEALEYSY
/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAA
AAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAAoIB
AAAAAAAAAAAAAAAAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgA
AAIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSw
E2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EgBYR
hJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAAoIBAAAAAAAAAAAAAAAA
AAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAA
AAIAAAAAAAAAAAIAAAAAAAAAAAAQAAAPhNACEYSY/l6E0AJghJj+AwAgAAAALgABAAAAAAAC
BAAAAAAAAAACAAAAAAAAAAAAEAAAD4SgBRGEmP5ehKAFYISY/gUAIAAAAC4AAQAuAAEAAAAE
AAIAAAAAAAAAAAIAAAAAAAAAAAAQAAAPhHAIEYSY/l6EcAhghJj+AwAgAAIAKQABAAAAFwAA
AAAAAAAAAAACAAAAAAAAAAAUEAAAD4RACxGEmP5ehEALYISY/k9KBgBRSgYAQ0oSAFBKBgBD
ShIAAQAiIAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhBAOEYSY/l6EEA5ghJj+T0oG
AFFKBgBDShIAUEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+E4BAR
hJj+XoTgEGCEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAA
AAAAAAAUEAAAD4SwExGEmP5ehLATYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAAX
AAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhIAWEYSY/l6EgBZghJj+T0oGAFFKBgBDShIAUEoG
AENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EUBkRhJj+XoRQGWCEmP5P
SgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAAAACAAAAAAAAAAACAAAAAAAAAAAAEAAAD4TQ
AhGEmP5ehNACYISY/gMAIAAAAC4AAQAAAAAAAgQAAAAAAAAAAgAAAAAAAAAAABAAAA+EoAUR
hJj+XoSgBWCEmP4FACAAAAAuAAEALgABAAAABAACAAAAAAAAAAACAAAAAAAAAAAAEAAAD4Rw
CBGEmP5ehHAIYISY/gMAIAACACkAAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EQAsR
hJj+XoRAC2CEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAA
AAAAAAAUEAAAD4QQDhGEmP5ehBAOYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAAX
AAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhOAQEYSY/l6E4BBghJj+T0oGAFFKBgBDShIAUEoG
AENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EsBMRhJj+XoSwE2CEmP5P
SgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAAAAAAAAAUEAAAD4SA
FhGEmP5ehIAWYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAAXAAAAAAAAAAAAAAIA
AAAAAAAAABQQAAAPhFAZEYSY/l6EUBlghJj+T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAA
AAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EaAERhJj+FcYFAAHQAgZehGgBYISY/odoAAAA
AIhIAAACAAAALgABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAAKGAAAD4QYAxGEUP4VxgUAAaAF
Bl6EGANghFD+h2gAAAAAiEgAAAQAAAAuAAEALgABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAK
GAAAD4TIBBGECP4VxgUAAXAIBl6EyARghAj+h2gAAAAAiEgAAAYAAAAuAAEALgACAC4AAQAA
AAAAAQMFBwAAAAAAAAAAAAAAAAAAChgAAA+EwAYRhHj9FcYFAAFACwZehMAGYIR4/YdoAAAA
AIhIAAAIAAAALgABAC4AAgAuAAMALgABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAAKGAAAD4S4
CBGE6PwVxgUAARAOBl6EuAhghOj8h2gAAAAAiEgAAAoAAAAuAAEALgACAC4AAwAuAAQALgAB
AAAAAAABAwUHCQsAAAAAAAAAAAAAAAAKGAAAD4SwChGEWPwVxgUAAeAQBl6EsApghFj8h2gA
AAAAiEgAAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAAAQMFBwkLDQAAAAAAAAAA
AAAAChgAAA+EqAwRhMj7FcYFAAEYFQZehKgMYITI+4doAAAAAIhIAAAOAAAALgABAC4AAgAu
AAMALgAEAC4ABQAuAAYALgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAAKGAAAD4SgDhGEOPsV
xgUAAegXBl6EoA5ghDj7h2gAAAAAiEgAABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAu
AAcALgABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAKGAAAD4TgEBGEYPoVxgUAAbgaBl6E4BBg
hGD6h2gAAAAAiEgAABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAC4AAQAA
AAAAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+E0AIRhJj+XoTQAmCEmP4DACAAAAAuAAEAAAAA
AAIEAAAAAAAAAAIAAAAAAAAAAAAQAAAPhKAFEYSY/l6EoAVghJj+BQAgAAAALgABAC4AAQAA
AAQAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+EcAgRhJj+XoRwCGCEmP4DACAAAgApAAEAAAAX
AAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhEALEYSY/l6EQAtghJj+T0oGAFFKBgBDShIAUEoG
AENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EEA4RhJj+XoQQDmCEmP5P
SgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAAAAAAAAAUEAAAD4Tg
EBGEmP5ehOAQYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAAXAAAAAAAAAAAAAAIA
AAAAAAAAABQQAAAPhLATEYSY/l6EsBNghJj+T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAA
ABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EgBYRhJj+XoSAFmCEmP5PSgYAUUoGAENKEgBQ
SgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAAAAAAAAAUEAAAD4RQGRGEmP5ehFAZYISY
/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAP
hNACEYSY/hXGBQAB0AIGXoTQAmCEmP5vKAABAAAAAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAA
ChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAAAoIBAAAA
AAAAAAAAAAAAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIA
AgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE
mP6HaAAAAACISAAAAgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EEA4RhJj+
FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAA
AAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAgAEA
AAAAAAAAAAAAAAAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAA
AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAW
YISY/odoAAAAAIhIAAACAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RQGRGE
TP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAAEAEAAAAAAAAAAABoAQAA
AAAAAA0YAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5vKACHaAAAAACISAAAAgAAAC4AAQAA
AAAQAQMAAAAAAAAAAGgBAAAAAAAADRgBAA+EsAERhFD+FcYFAAGQAAZehLABYIRQ/m8oAIdo
AAAAAIhIAAAEAAAALgABAC4AAQAAAAAQAQMFAAAAAAAAAGgBAAAAAAAADRgCAA+EyAQRhAj+
FcYFAAGgBQZehMgEYIQI/m8oAIdoAAAAAIhIAAAGAAAALgABAC4AAgAuAAEAAAAAEAEDBQcA
AAAAAABoAQAAAAAAAA0YAwAPhMAGEYR4/RXGBQABcAgGXoTABmCEeP1vKACHaAAAAACISAAA
CAAAAC4AAQAuAAIALgADAC4AAQAAAAAQAQMFBwkAAAAAAGgBAAAAAAAADRgEAA+EuAgRhOj8
FcYFAAHYCQZehLgIYITo/G8oAIdoAAAAAIhIAAAKAAAALgABAC4AAgAuAAMALgAEAC4AAQAA
AAAQAQMFBwkLAAAAAGgBAAAAAAAADRgFAA+EsAoRhFj8FcYFAAGoDAZehLAKYIRY/G8oAIdo
AAAAAIhIAAAMAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAEAAAAAEAEDBQcJCw0AAABoAQAA
AAAAAA0YBgAPhKgMEYTI+xXGBQABEA4GXoSoDGCEyPtvKACHaAAAAACISAAADgAAAC4AAQAu
AAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAQAQMFBwkLDQ8AAGgBAAAAAAAADRgHAA+EoA4R
hDj7FcYFAAHgEAZehKAOYIQ4+28oAIdoAAAAAIhIAAAQAAAALgABAC4AAgAuAAMALgAEAC4A
BQAuAAYALgAHAC4AAQAAAAAQAQMFBwkLDQ8RAGgBAAAAAAAADRgIAA+E4BARhGD6FcYFAAGw
EwZehOAQYIRg+m8oAIdoAAAAAIhIAAASAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAH
AC4ACAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAA4YAAAPhNACEYSY/hXGBQAB0AIGXoTQ
AmCEmP5DShgAh2gAAAAAiEgAAAEAAAABAAAABAABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4Sg
BRGEmP4VxgUAAaAFBl6EoAVghJj+h2gAAAAAiEgAAAIAAQAuAAEAAAACAgEAAAAAAAAAAAAA
AAAAAAAAAAoYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP+HaAAAAACISAAAAgACAC4AAQAA
AAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/odoAAAA
AIhIAAACAAMALgABAAAABAABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4QQDhGEmP4VxgUAARAO
Bl6EEA5ghJj+h2gAAAAAiEgAAAIABAAuAAEAAAACAgEAAAAAAAAAAAAAAAAAAAAAAAoYAAAP
hOAQEYRM/xXGBQAB4BAGXoTgEGCETP+HaAAAAACISAAAAgAFAC4AAQAAAAAAAQAAAAAAAAAA
AAAAAAAAAAAAChgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/odoAAAAAIhIAAACAAYALgAB
AAAABAABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+h2gA
AAAAiEgAAAIABwAuAAEAAAACAgEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhFAZEYRM/xXGBQAB
UBkGXoRQGWCETP+HaAAAAACISAAAAgAIAC4AAQAAAAAQAQAAAAAAAAAAAGgBAAAAAAAAChgA
AA+E0AIRhJj+FcYFAAHQAgZehNACYISY/odoAAAAAIhIAAACAAAALgABAAAABJABAAAAAAAA
AAAAaAEAAAAAAAAKGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+h2gAAAAAiEgAAAIAAQAu
AAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP+H
aAAAAACISAAAAgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EQAsRhJj+FcYF
AAFACwZehEALYISY/odoAAAAAIhIAAACAAMALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAK
GAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+h2gAAAAAiEgAAAIABAAuAAEAAAACkgEAAAAA
AAAAAABoAQAAAAAAAAoYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP+HaAAAAACISAAAAgAF
AC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY
/odoAAAAAIhIAAACAAYALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4SAFhGEmP4V
xgUAAYAWBl6EgBZghJj+h2gAAAAAiEgAAAIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAA
AAoYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP+HaAAAAACISAAAAgAIAC4AAQAAABcAAAAA
AAAAAAAAAGgBAAAAAAAAFRgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAQBRSgEAbygA
h2gAAAAAiEgAAAEAt/ABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SgBRGEmP4VxgUA
AaAFBl6EoAVghJj+h2gAAAAAiEgAAAIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAoY
AAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP+HaAAAAACISAAAAgACAC4AAQAAAACAAQAAAAAA
AAAAAAAAAAAAAAAAChgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/odoAAAAAIhIAAACAAMA
LgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+
h2gAAAAAiEgAAAIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhOAQEYRM/xXG
BQAB4BAGXoTgEGCETP+HaAAAAACISAAAAgAFAC4AAQAAAACAAQAAAAAAAAAAAAAAAAAAAAAA
ChgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/odoAAAAAIhIAAACAAYALgABAAAABIABAAAA
AAAAAAAAAAAAAAAAAAAKGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+h2gAAAAAiEgAAAIA
BwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCE
TP+HaAAAAACISAAAAgAIAC4AAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EIAERhCAB
FcYFAAEgAQZehCABYIQgAU9KAQBRSgEAbygAh2gAAAAAiEgAAAEALQABAAAAFxAAAAAAAAAA
AAAAaAEAAAAAAAAZGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oHAFFKBwBeSgcAbygA
h2gAAAAAiEgAAAEAbwABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RwCBGEmP4VxgUA
AXAIBl6EcAhghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXEAAAAAAAAAAAAABo
AQAAAAAAABUYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhI
AAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAO
YISY/k9KBwBRSgcAXkoHAG8oAIdoAAAAAIhIAAABAG8AAQAAABcQAAAAAAAAAAAAAGgBAAAA
AAAAFRgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEA
p/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+
T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABkYAAAP
hIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgcAUUoHAF5KBwBvKACHaAAAAACISAAAAQBvAAEA
AAAXEAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSggA
UUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EaAER
hJj+FcYFAAHQAgZehGgBYISY/odoAAAAAIhIAAACAAAALgABAAAAAAABAwAAAAAAAAAAAAAA
AAAAAAAKGAAAD4QYAxGEUP4VxgUAAaAFBl6EGANghFD+h2gAAAAAiEgAAAQAAAAuAAEALgAB
AAAAAAABAwUAAAAAAAAAAAAAAAAAAAAKGAAAD4TIBBGECP4VxgUAAXAIBl6EyARghAj+h2gA
AAAAiEgAAAYAAAAuAAEALgACAC4AAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAChgAAA+EwAYR
hHj9FcYFAAFACwZehMAGYIR4/YdoAAAAAIhIAAAIAAAALgABAC4AAgAuAAMALgABAAAAAAAB
AwUHCQAAAAAAAAAAAAAAAAAKGAAAD4S4CBGE6PwVxgUAARAOBl6EuAhghOj8h2gAAAAAiEgA
AAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAAKGAAAD4Sw
ChGEWPwVxgUAAeAQBl6EsApghFj8h2gAAAAAiEgAAAwAAAAuAAEALgACAC4AAwAuAAQALgAF
AC4AAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAChgAAA+EqAwRhMj7FcYFAAEYFQZehKgMYITI
+4doAAAAAIhIAAAOAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAAAAABAwUHCQsN
DwAAAAAAAAAAAAAKGAAAD4SgDhGEOPsVxgUAAegXBl6EoA5ghDj7h2gAAAAAiEgAABAAAAAu
AAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAK
GAAAD4TgEBGEYPoVxgUAAbgaBl6E4BBghGD6h2gAAAAAiEgAABIAAAAuAAEALgACAC4AAwAu
AAQALgAFAC4ABgAuAAcALgAIAC4AAQAAAAAAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+E0AIR
hJj+XoTQAmCEmP4DACAAAAAuAAEAAAAAAAIEAAAAAAAAAAIAAAAAAAAAAAAQAAAPhKAFEYSY
/l6EoAVghJj+BQAgAAAALgABAC4AAQAAAAQAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+EcAgR
hJj+XoRwCGCEmP4DACAAAgApAAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhEALEYSY
/l6EQAtghJj+T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAA
AAAAFBAAAA+EEA4RhJj+XoQQDmCEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAA
AAAAAAAAAAACAAAAAAAAAAAUEAAAD4TgEBGEmP5ehOAQYISY/k9KBgBRSgYAQ0oSAFBKBgBD
ShIAAQAiIAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhLATEYSY/l6EsBNghJj+T0oG
AFFKBgBDShIAUEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EgBYR
hJj+XoSAFmCEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAA
AAAAAAAUEAAAD4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAAX
EAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoB
AG8oAIdoAAAAAIhIAAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EoAURhJj+
FcYFAAGgBQZehKAFYISY/k9KBwBRSgcAXkoHAG8oAIdoAAAAAIhIAAABAG8AAQAAABcQAAAA
AAAAAAAAAGgBAAAAAAAAFRgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KCABRSggAbygA
h2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RACxGEmP4VxgUA
AUALBl6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXEAAAAAAAAAAAAABo
AQAAAAAAABkYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgcAUUoHAF5KBwBvKACHaAAA
AACISAAAAQBvAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhOAQEYSY/hXGBQAB4BAG
XoTgEGCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABcQAAAAAAAAAAAAAGgBAAAA
AAAAFRgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEA
t/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+
T0oHAFFKBwBeSgcAbygAh2gAAAAAiEgAAAEAbwABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAV
GAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEA
AAAXEAAAAAAAAAAAAABoAQAAAAAAABYYAAAPhNACEYQAABXGBQAB0AIGXoTQAmCEAABDShgA
T0oBAFFKAQCHaAAAAACISAAAAQAtAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhKAF
EYSY/hXGBQABoAUGXoSgBWCEmP5PSgcAUUoHAF5KBwBvKACHaAAAAACISAAAAQBvAAEAAAAX
EAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSggAUUoI
AG8oAIdoAAAAAIhIAAABAKfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EQAsRhJj+
FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAFxAAAAAAAAAA
AAAAaAEAAAAAAAAZGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oHAFFKBwBeSgcAbygA
h2gAAAAAiEgAAAEAbwABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4TgEBGEmP4VxgUA
AeAQBl6E4BBghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXEAAAAAAAAAAAAABo
AQAAAAAAABUYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhI
AAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EgBYRhJj+FcYFAAGAFgZehIAW
YISY/k9KBwBRSgcAXkoHAG8oAIdoAAAAAIhIAAABAG8AAQAAABcQAAAAAAAAAAAAAGgBAAAA
AAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEA
p/ABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+
h2gAAAAAiEgAAAIAAAApAAEAAAAEEAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhKAFEYSY/hXG
BQABoAUGXoSgBWCEmP6HaAAAAACISAAAAgABAC4AAQAAAAISAQAAAAAAAAAAAGgBAAAAAAAA
ChgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/4doAAAAAIhIAAACAAIALgABAAAAABABAAAA
AAAAAAAAaAEAAAAAAAAKGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+h2gAAAAAiEgAAAIA
AwAuAAEAAAAEEAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCE
mP6HaAAAAACISAAAAgAEAC4AAQAAAAISAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+E4BARhEz/
FcYFAAHgEAZehOAQYIRM/4doAAAAAIhIAAACAAUALgABAAAAABABAAAAAAAAAAAAaAEAAAAA
AAAKGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+h2gAAAAAiEgAAAIABgAuAAEAAAAEEAEA
AAAAAAAAAABoAQAAAAAAAAoYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP6HaAAAAACISAAA
AgAHAC4AAQAAAAISAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EUBkRhEz/FcYFAAFQGQZehFAZ
YIRM/4doAAAAAIhIAAACAAgALgABAAAAFxAAAAAAAAAAAAAA0AIAAAAAAAAVGAAAD4TQAhGE
AAAVxgUAAdACBl6E0AJghAAAT0oBAFFKAQBvKACHaAAAAACISAAAAQAtAAEAAAAXkAAAAAAA
AAAAAADQAgAAAAAAABkYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgcAUUoHAF5KBwBv
KACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAADQAgAAAAAAABUYAAAPhHAIEYSY/hXG
BQABcAgGXoRwCGCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAA
ANACAAAAAAAAFRgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAh2gAAAAA
iEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAA0AIAAAAAAAAZGAAAD4QQDhGEmP4VxgUAARAOBl6E
EA5ghJj+T0oHAFFKBwBeSgcAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAA0AIA
AAAAAAAVGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oIAFFKCABvKACHaAAAAACISAAA
AQCn8AEAAAAXkAAAAAAAAAAAAADQAgAAAAAAABUYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CE
mP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAANACAAAAAAAAGRgA
AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBwBRSgcAXkoHAG8oAIdoAAAAAIhIAAABAG8A
AQAAABeQAAAAAAAAAAAAANACAAAAAAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9K
CABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4TQ
AhGEAAAVxgUAAdACBl6E0AJghAAAT0oBAFFKAQBvKACHaAAAAACISAAAAQAtAAEAAAAXEAAA
AAAAAAAAAABoAQAAAAAAABkYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgcAUUoHAF5K
BwBvKACHaAAAAACISAAAAQBvAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhHAIEYSY
/hXGBQABcAgGXoRwCGCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABcQAAAAAAAA
AAAAAGgBAAAAAAAAFRgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAh2gA
AAAAiEgAAAEAt/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4QQDhGEmP4VxgUAARAO
Bl6EEA5ghJj+T0oHAFFKBwBeSgcAbygAh2gAAAAAiEgAAAEAbwABAAAAFxAAAAAAAAAAAAAA
aAEAAAAAAAAVGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oIAFFKCABvKACHaAAAAACI
SAAAAQCn8AEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhLATEYSY/hXGBQABsBMGXoSw
E2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAA
GRgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBwBRSgcAXkoHAG8oAIdoAAAAAIhIAAAB
AG8AAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY
/k9KCABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAABABAAAAAAAAAAAAaAEAAAAAAAANGAAA
D4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+bygAh2gAAAAAiEgAAAIAAAAuAAEAAAAAEAEDAAAA
AAAAAABoAQAAAAAAAA0YAQAPhFAHEYRQ/hXGBQABMAYGXoRQB2CEUP5vKACHaAAAAACISAAA
BAAAAC4AAQAuAAEAAAAAEAEDBQAAAAAAAABoAQAAAAAAAA0YAgAPhAAJEYQI/hXGBQAB2AkG
XoQACWCECP5vKACHaAAAAACISAAABgAAAC4AAQAuAAIALgABAAAAABABAwUHAAAAAAAAaAEA
AAAAAAANGAMAD4T4ChGEeP0VxgUAAagMBl6E+ApghHj9bygAh2gAAAAAiEgAAAgAAAAuAAEA
LgACAC4AAwAuAAEAAAAAEAEDBQcJAAAAAABoAQAAAAAAAA0YBAAPhPAMEYTo/BXGBQABEA4G
XoTwDGCE6PxvKACHaAAAAACISAAACgAAAC4AAQAuAAIALgADAC4ABAAuAAEAAAAAEAEDBQcJ
CwAAAABoAQAAAAAAAA0YBQAPhOgOEYRY/BXGBQAB4BAGXoToDmCEWPxvKACHaAAAAACISAAA
DAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgABAAAAABABAwUHCQsNAAAAaAEAAAAAAAANGAYA
D4TgEBGEyPsVxgUAAUgSBl6E4BBghMj7bygAh2gAAAAAiEgAAA4AAAAuAAEALgACAC4AAwAu
AAQALgAFAC4ABgAuAAEAAAAAEAEDBQcJCw0PAABoAQAAAAAAAA0YBwAPhNgSEYQ4+xXGBQAB
GBUGXoTYEmCEOPtvKACHaAAAAACISAAAEAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A
BwAuAAEAAAAAEAEDBQcJCw0PEQBoAQAAAAAAAA0YCAAPhBgVEYRg+hXGBQAB6BcGXoQYFWCE
YPpvKACHaAAAAACISAAAEgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgALgAB
AAAAAAACAAAAAAAAAAACAAAAAAAAAAAAEAAAD4TQAhGEmP5ehNACYISY/gMAIAAAAC4AAQAA
AAAAAgQAAAAAAAAAAgAAAAAAAAAAABAAAA+EoAURhJj+XoSgBWCEmP4FACAAAAAuAAEALgAB
AAAABAACAAAAAAAAAAACAAAAAAAAAAAAEAAAD4RwCBGEmP5ehHAIYISY/gMAIAACACkAAQAA
ABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EQAsRhJj+XoRAC2CEmP5PSgYAUUoGAENKEgBQ
SgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAAAAAAAAAUEAAAD4QQDhGEmP5ehBAOYISY
/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAP
hOAQEYSY/l6E4BBghJj+T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAA
AgAAAAAAAAAAFBAAAA+EsBMRhJj+XoSwE2CEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiAB
AAAAFwAAAAAAAAAAAAACAAAAAAAAAAAUEAAAD4SAFhGEmP5ehIAWYISY/k9KBgBRSgYAQ0oS
AFBKBgBDShIAAQAiIAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhFAZEYSY/l6EUBlg
hJj+T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAAAAQAAgAAAAAAAAAAAAAAAAAAAAAAAxgA
AA+E0AIRhJj+FcYFAAHQAgZehNACYISY/m8oAAMAKAAAACkAAQAAAASAAQAAAAAAAAAAAAAA
AAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAA
AoIBAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAA
iEgAAAIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsG
XoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+E
EA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAAoIBAAAAAAAAAAAA
AAAAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEA
AAAAgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAA
AACISAAAAgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGA
FgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAKGAAA
D4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAAEAEAAAAAAAAA
AABoAQAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5vKAABAAAAAQAAAASQAQAA
AAAAAAAAAGgBAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAAC
AAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhg
hEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhEALEYSY
/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAA
AAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAApIB
AAAAAAAAAAAAaAEAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgA
AAIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSw
E2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EgBYR
hJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAApIBAAAAAAAAAAAAaAEA
AAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAX
EAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhCABEYQgARXGBQABIAEGXoQgAWCEIAFPSgAAUUoA
AF5KAABvKACHaAAAAACISAAAAQAqAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhKAF
EYSY/hXGBQABoAUGXoSgBWCEmP5PSgcAUUoHAF5KBwBvKACHaAAAAACISAAAAQBvAAEAAAAX
kAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSggAUUoI
AG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EQAsRhJj+
FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAA
AAAAaAEAAAAAAAAZGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oHAFFKBwBeSgcAbygA
h2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4TgEBGEmP4VxgUA
AeAQBl6E4BBghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABo
AQAAAAAAABUYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhI
AAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EgBYRhJj+FcYFAAGAFgZehIAW
YISY/k9KBwBRSgcAXkoHAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA
AAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEA
p/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+
T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAP
hAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgcAUUoHAF5KBwBvKACHaAAAAACISAAAAQBvAAEA
AAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSggA
UUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+EqAwR
hJj+FcYFAAGoDAZehKgMYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAA
AAAAAAAAaAEAAAAAAAAZGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oHAFFKBwBeSgcA
bygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RIEhGEmP4V
xgUAAUgSBl6ESBJghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAA
AABoAQAAAAAAABUYAAAPhBgVEYSY/hXGBQABGBUGXoQYFWCEmP5PSgEAUUoBAG8oAIdoAAAA
AIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+E6BcRhJj+FcYFAAHoFwZe
hOgXYISY/k9KBwBRSgcAXkoHAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgB
AAAAAAAAFRgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/k9KCABRSggAbygAh2gAAAAAiEgA
AAEAp/AAAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAATGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJg
hJj+T0oAAFBKAABRSgAAXkoAAG8oAAEALQABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAZGAAA
D4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oHAFFKBwBeSgcAbygAh2gAAAAAiEgAAAEAbwAB
AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oI
AFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhEAL
EYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeAAAAA
AAAAAAAAAAAAAAAAAAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBwBRSgcAXkoH
AG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+E4BARhJj+
FcYFAAHgEAZehOAQYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAF4AAAAAAAAAA
AAAAAAAAAAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKACHaAAA
AACISAAAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABkYAAAPhIAWEYSY/hXGBQABgBYG
XoSAFmCEmP5PSgcAUUoHAF5KBwBvKACHaAAAAACISAAAAQBvAAEAAAAXgAAAAAAAAAAAAAAA
AAAAAAAAABUYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSggAUUoIAG8oAIdoAAAAAIhI
AAABAKfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E0AIRhJj+FcYFAAHQAgZehNAC
YISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZ
GAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oHAFFKBwBeSgcAbygAh2gAAAAAiEgAAAEA
bwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+
T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAP
hEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQ
AAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBwBRSgcA
XkoHAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E4BAR
hJj+FcYFAAHgEAZehOAQYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAA
AAAAAAAAaAEAAAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKACH
aAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhIAWEYSY/hXGBQAB
gBYGXoSAFmCEmP5PSgcAUUoHAF5KBwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAA
AABoAQAAAAAAABUYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSggAUUoIAG8oAIdoAAAA
AIhIAAABAKfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E0AIRhJj+FcYFAAHQAgZe
hNACYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAA
AAAZGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oHAFFKBwBeSgcAbygAh2gAAAAAiEgA
AAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhg
hJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUY
AAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAA
ABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBwBR
SgcAXkoHAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E
4BARhJj+FcYFAAHgEAZehOAQYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AA
AAAAAAAAAAAAaAEAAAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBv
KACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhIAWEYSY/hXG
BQABgBYGXoSAFmCEmP5PSgcAUUoHAF5KBwBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAA
AAAAAABoAQAAAAAAABUYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSggAUUoIAG8oAIdo
AAAAAIhIAAABAKfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EaAERhJj+FcYFAAHQ
AgZehGgBYISY/odoAAAAAIhIAAACAAAALgABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAAKGAAA
D4QYAxGEUP4VxgUAAaAFBl6EGANghFD+h2gAAAAAiEgAAAQAAAAuAAEALgABAAAAAAABAwUA
AAAAAAAAAAAAAAAAAAAKGAAAD4TIBBGECP4VxgUAAXAIBl6EyARghAj+h2gAAAAAiEgAAAYA
AAAuAAEALgACAC4AAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAChgAAA+EwAYRhHj9FcYFAAFA
CwZehMAGYIR4/YdoAAAAAIhIAAAIAAAALgABAC4AAgAuAAMALgABAAAAAAABAwUHCQAAAAAA
AAAAAAAAAAAKGAAAD4S4CBGE6PwVxgUAARAOBl6EuAhghOj8h2gAAAAAiEgAAAoAAAAuAAEA
LgACAC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAAKGAAAD4SwChGEWPwVxgUA
AeAQBl6EsApghFj8h2gAAAAAiEgAAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAA
AQMFBwkLDQAAAAAAAAAAAAAAChgAAA+EqAwRhMj7FcYFAAEYFQZehKgMYITI+4doAAAAAIhI
AAAOAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAAAAABAwUHCQsNDwAAAAAAAAAA
AAAKGAAAD4SgDhGEOPsVxgUAAegXBl6EoA5ghDj7h2gAAAAAiEgAABAAAAAuAAEALgACAC4A
AwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAKGAAAD4TgEBGE
YPoVxgUAAbgaBl6E4BBghGD6h2gAAAAAiEgAABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4A
BgAuAAcALgAIAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EaAERhJj+FcYFAAHQ
AgZehGgBYISY/odoAAAAAIhIAAACAAAALgABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAAKGAAA
D4QYAxGEUP4VxgUAAaAFBl6EGANghFD+h2gAAAAAiEgAAAQAAAAuAAEALgABAAAAAAABAwUA
AAAAAAAAAAAAAAAAAAAKGAAAD4TIBBGECP4VxgUAAXAIBl6EyARghAj+h2gAAAAAiEgAAAYA
AAAuAAEALgACAC4AAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAChgAAA+EwAYRhHj9FcYFAAFA
CwZehMAGYIR4/YdoAAAAAIhIAAAIAAAALgABAC4AAgAuAAMALgABAAAAAAABAwUHCQAAAAAA
AAAAAAAAAAAKGAAAD4S4CBGE6PwVxgUAARAOBl6EuAhghOj8h2gAAAAAiEgAAAoAAAAuAAEA
LgACAC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAAKGAAAD4SwChGEWPwVxgUA
AeAQBl6EsApghFj8h2gAAAAAiEgAAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAA
AQMFBwkLDQAAAAAAAAAAAAAAChgAAA+EqAwRhMj7FcYFAAEYFQZehKgMYITI+4doAAAAAIhI
AAAOAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAAAAABAwUHCQsNDwAAAAAAAAAA
AAAKGAAAD4SgDhGEOPsVxgUAAegXBl6EoA5ghDj7h2gAAAAAiEgAABAAAAAuAAEALgACAC4A
AwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAKGAAAD4TgEBGE
YPoVxgUAAbgaBl6E4BBghGD6h2gAAAAAiEgAABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4A
BgAuAAcALgAIAC4AAQAAAAAAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+E0AIRhJj+XoTQAmCE
mP4DACAAAAAuAAEAAAAAAAIEAAAAAAAAAAIAAAAAAAAAAAAQAAAPhKAFEYSY/l6EoAVghJj+
BQAgAAAALgABAC4AAQAAAAQAAgAAAAAAAAAAAgAAAAAAAAAAABAAAA+EcAgRhJj+XoRwCGCE
mP4DACAAAgApAAEAAAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhEALEYSY/l6EQAtghJj+
T0oGAFFKBgBDShIAUEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+E
EA4RhJj+XoQQDmCEmP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAAC
AAAAAAAAAAAUEAAAD4TgEBGEmP5ehOAQYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiIAEA
AAAXAAAAAAAAAAAAAAIAAAAAAAAAABQQAAAPhLATEYSY/l6EsBNghJj+T0oGAFFKBgBDShIA
UEoGAENKEgABACIgAQAAABcAAAAAAAAAAAAAAgAAAAAAAAAAFBAAAA+EgBYRhJj+XoSAFmCE
mP5PSgYAUUoGAENKEgBQSgYAQ0oSAAEAIiABAAAAFwAAAAAAAAAAAAACAAAAAAAAAAAUEAAA
D4RQGRGEmP5ehFAZYISY/k9KBgBRSgYAQ0oSAFBKBgBDShIAAQAiICIAAAA+GlYOAAAAAAAA
AAAAAAAAAgAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAA
O0QLLQAAAAAAAAAAAAAAAB12cX8AAAAAAAAAAAAAAABDGRoPAAAAAAAAAAAAAAAAljvAbQAA
AAAAAAAAAAAAAD48xkAAAAAAAAAAAAAAAABNU10GAAAAAAAAAAAAAAAAEUx3QAAAAAAAAAAA
AAAAAC0wISwAAAAAAAAAAAAAAAABc/FtAAAAAAAAAAAAAAAAaWuKdgAAAAAAAAAAAAAAAJ8y
yRAAAAAAAAAAAAAAAABLMw0vAAAAAAAAAAAAAAAAIx/hCQAAAAAAAAAAAAAAAF4iwjwAAAAA
AAAAAAAAAACfMskQAAAAAPxemQUJAAAA2XrtVgAAAAAAAAAAAAAAAGY+VlMAAAAAAAAAAAAA
AABNFnUtAAAAAAAAAAAAAAAAk3ZlSQAAAAAAAAAAAACaMHhW1DEAAAAAAAAAAAAAAACVYgYQ
AAAAAAAAAAAAAAAAz2oCHgAAAAAAAAAAAAAAAMpJ0QIAAAAAAAAAAAAAmjDaaB5TAAAAAAAA
AAAAAAAA3ljAKQAAAAAAAAAAAACaMAIYHC4AAAAAAAAAAAAAAAAFAwY0AAAAAAAAAAAAAAAA
FEBEKgAAAAAAAAAAAAAAALhiriQAAAAAAAAAAAAAAAD4OxFCAAAAAAAAAAAAAAAA////////
////////////////////////////////////////////////////////////////////////
/////////////////////wEAAAAQAFwAAQAAAJEmrQABAAAAUgBlAAEAAABTAG4AAQAAABQA
AAABAAAAFSQBDQEAAABWAQBAAQAAABcIgUIBAAAAGABRSv//////////////////////////
////////////////////////////////////////////////////////IQAAAAAAAAAAAAAA
AAAAAAcAVwBXADgATgB1AG0AMQAAAAAAAAAAAAAAAAAAAAgAVwBXADgATgB1AG0AMQAzAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAFcAVwA4AE4AdQBtADEAMgAJAFcAVwA4AE4A
dQBtADEAMwAyAAkAVwBXADgATgB1AG0AMQAzADMAAAD//yEAAAAAAAAAAAASAAEACQQZAAkE
GwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBAAAAAAAAAAAEgDOrzC+GQAJBBsACQQPAAkE
GQAJBBsACQQPAAkEGQAJBBsACQQSADTs1mEZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkE
GwAJBAAAEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAOxbVGkZAAkE
GwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBAAAAAAAAAAAAAAAABIASC8GgQMACQQFAAkE
AQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAAAAAAAAEgBUGSBKGQAJBBsACQQPAAkEGQAJBBsA
CQQPAAkEGQAJBBsACQQSAM6vML4ZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIA
+JdqKgMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgABAAkEAwAJBAUACQQBAAkE
AwAJBAUACQQBAAkEAwAJBAUACQQSAKRsuCUDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkE
BQAJBBIAAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgABAAkEAwAJBAUA
CQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQAAAAAAADFAAAABAAAAAgAAADlAAAAAAAAAMQA
AAB/WAEAt0MDAGUXBQCqPwUAfDMHABIZCQDMSQkA7GAMAHMSDQAkbA4A9QoQAPV0FwBzYxgA
lVgaAGlcGgCYZBoA1k8cABRHHQANPR4AKmEfAB4MIADFDSAAP3kgAHZ7IgD6VSQAWwMlADhT
KABjDCkAs0EpAFBuKQDnMSsAQ2ErAKAALQDcIi0A/GsuAHVVLwA9fjgAWS85AAJZOQAbDjoA
TiU6AH88OwAyGDwAL1Q8AIIQPQABQD0AmyM+ANFBPwD5BUMAKXtDAO0WRQDrUUUAbABGACJT
SgDMN0sAK19LAPd4TQAQNE4AUGROAP5ZTwA3UFAA2XpRABhAVgCRQVYAOxBXAA0qWAC1LVoA
fApbAKZaWwDrYVsAOwJhAKc0YQB6RmUAsUpmAJkPZwBQWmcAE2RnAJFqZwBdH2gAQl1sAMtp
bQDEEHAAdR5wAD8ecQAWGHIAymBzAO51cwDZDHQAE3J0ABkJdQAiQXUAmER1AFxddgAUUncA
dXl4AKVHeQD1aXkAIHJ5AEUPewB1S3sAiHh8ACxRfQDCa30AkyGBAH4+ggARYoMAOXGEAGs8
hgDfc4YADDSHAMwriABqV4kAyW2JAE8uigBbWooACTGLAAVOjADhT4wAyCCNAGcnkADWS5IA
ck2SADhIkwDBBpQAeR6UABJYlABCQZUAYWqVAN9ZlgCPKJgAZBKZADV9mQBxY5oATnWdACFw
ngDubKAABA2hAEIRogDsb6IAZyqlAD9OpwCMHqkAmy2sAA9CrACVJq0ADQquAMdfsQBdJbIA
FAazAF9FtAALQbUALX21AFt1twC3X7gA+S+5ABouugBGSrsAh0a9AAEBwACeIsUA4V7FADk9
ygC7Rc0AVyHQAFIt0QA+XtEAPlXSAGhh0gCnf9IAEXPTADJ/0wDeVdUA40TWAKI12ADpA9kA
ChDaAHlA2wCyQ90AlhHjAO965ABrfuUA7BzmACNF6AAUb+gAqC3sABIb7wADcPEA+HDzANYe
9gAsQPYA3Q73AE0i9wBuZvkA6kj6AM4z+wB4Dv0AQgj+AAAAAAABAAAAHQYAALwdAACqIAAA
RyIAANwkAAA4JgAAGjgAAHY4AAB9OAAAQjoAAEM6AABLOgAA2DwAANk8AADfPAAAPT0AAD49
AABDPQAAlD0AAJU9AACcPQAA9T0AAPY9AAD7PQAAUj4AAFM+AABZPgAA6j8AAOs/AADxPwAA
j0AAAJBAAACVQAAAW0EAAFxBAABhQQAAnkEAAJ9BAAClQQAA1kEAANdBAADcQQAAZEIAAGVC
AABqQgAAhkIAAIdCAABDQwAAM0UAAMlGAADNRgAABEgAAAVIAAALSAAA+koAAPtKAAACSwAA
NEwAADVMAAB1UAAAfFAAAC5XAAAvVwAANVcAAMxYAADNWAAA0lgAABxaAAAdWgAAzFoAANJa
AADAXQAAwV0AAMhdAAAHYAAACGAAABFgAACCYQAAg2EAAI1hAABgYwAAYWMAAGdjAAAdaQAA
HmkAALbRAADa0QAA6tEAAPHRAAD20QAA/tEAAATSAAAF0gAAEtIAABPSAAAn0gAALNIAADXS
AAA30gAAOdIAADrSAABP0gAAV9IAAGLSAABk0gAAZtIAAGfSAAB80gAAhtIAAJHSAACT0gAA
ldIAAJbSAACr0gAAtNIAAL/SAADB0gAAw9IAAMTSAADa0gAA49IAAO/SAADx0gAA89IAAPTS
AAAK0wAAE9MAAB3TAAAf0wAAIdMAACLTAAAz0wAAO9MAAEPTAABF0wAAR9MAAEjTAABa0wAA
Y9MAAGzTAABu0wAAcNMAAHHTAACE0wAAj9MAAJnTAACb0wAAndMAAJ7TAACx0wAAudMAAMPT
AADF0wAAx9MAAMjTAADc0wAA49MAAO7TAADw0wAA8tMAAPPTAAAI1AAAEdQAABzUAAAe1AAA
INQAACHUAAA21AAAQtQAAE3UAABP1AAAUdQAAFLUAABn1AAActQAAH3UAAB/1AAAgdQAAILU
AACY1AAAo9QAAK/UAACx1AAAvNQAAL3UAADT1AAA3tQAAOvUAADt1AAA+NQAAPnUAAAK1QAA
C9UAABrVAAAk1QAALNUAAC7VAAA51QAAOtUAAEnVAABS1QAAW9UAAF3VAABo1QAAadUAAHfV
AACA1QAAitUAAIzVAACW1QAAl9UAAKTVAACs1QAAuNUAALrVAADM1QAAzdUAANrVAADh1QAA
7dUAAO/VAAAJ1gAACtYAABfWAAAe1gAAKtYAACzWAAA31gAAONYAAEHWAABI1gAAU9YAAFXW
AABc1gAAXdYAAGbWAABx1gAAfdYAAH/WAACq1gAAq9YAALTWAAC/1gAAy9YAAM3WAADV1gAA
1tYAAOXWAADm1gAA79YAAPvWAAAH1wAAEtcAACrXAAAr1wAANNcAAD/XAABL1wAAVtcAAGzX
AABt1wAAd9cAAILXAACO1wAAmdcAAKLXAACj1wAArdcAALjXAADE1wAAz9cAAAbYAAAH2AAA
EdgAABzYAAAp2AAANNgAAEnYAABK2AAAXtgAAF/YAABw2AAAe9gAAInYAACQ2AAAmtgAAJvY
AACs2AAAt9gAAMXYAADN2AAA6tgAAOvYAAAH2QAACNkAABnZAAAj2QAAK9kAADTZAABF2QAA
RtkAAFbZAABf2QAAZ9kAAHDZAABy2QAAc9kAAIDZAACB2QAAkNkAAJfZAACi2QAArdkAAK/Z
AACw2QAAv9kAAMbZAADR2QAA2tkAANzZAADd2QAA6tkAAOvZAAD62QAABdoAABHaAAAc2gAA
HtoAAB/aAAAu2gAANtoAAEHaAABK2gAAUdoAAFLaAACF2gAAAAAAAAEAAAABAAAABQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAACAAAAAIBAAACAQAAngEABAIBAAACAQAAngEABAIBAAACAQAA
ngEABAIBAAACAQAAngEABAIBAAACAQAAngEABAIBAAACAQAAngEABAIBAAACAQAAngEABAIB
AAACAQAAngEABAIBAAACAQAAngEABAIBAAACAQAAngEABAIBAAACAQAAngEABAIBAAACAQAA
ngEABAIBAAACAQAAlgEABAEAAAABAAAACAAAAAIBAAACAQAAngEABAIBAAACAQAAngEABAIB
AAACAQAAlgEABAgAAAACAQAAAgEAAJ4BAAQCAQAAAgEAAJ4BAAQCAQAAAgEAAJYBAAQIAAAA
AgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIBAACeAQAEAgEAAAIB
AACWAQAEAAAAAAgAAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAQCAQAAngEABAIBAAACAQAA
AgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIB
AAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAA
ngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIB
AAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAA
AgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIB
AAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAA
ngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIB
AACeAQAEAgEAAAIBAAACAQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAAgEAAAIBAACeAQAE
AgEAAAIBAAACAQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAAgEAAAIBAACeAQAEAgEAAAIB
AAACAQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAA
AgEAAAIBAACeAQAEAgEAAAIBAAACAQAAAgEAAAIBAACeAQAEAgEAAAIBAAACAQAAAgEAAAIB
AACeAQAEAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAA
AgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAAgEAAJ4B
AAQCAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAQCAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAA
ngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAACeAQAEAgEAAAIBAAACAQAAAgEAAAIB
AACeAQAEAgEAAAIBAAACAQAAAgEAAAIBAACeAQAEAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAA
AgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAQCAQAAngEABAIBAAACAQAAAgEAAAIB
AAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAlgEABP9AAwABALwdAAAzHgAA3Bv6BwEA
AQC8HQAAAQAAALwdAAAAAAAAAhAAAAAAAAAAhNoAAHAAABAAQAAA//8CAAAABwBVAG4AawBu
AG8AdwBuAAgARQBkACAAUwBoAGEAeQBhAP//AgAIAAAAAAAAAAAAAAAAAAAAAAAAAAEA//8C
AAAAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAkAAABHFpABAAACAgYDBQQFAgMEhzoA
IAAAAAAAAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1
FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz
JpABAAACCwYEAgICAgIEhzoAIAAAAAAAAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAARTWQ
AQAAAgsGCQQFBAICBI8CAIAAGAAAAAAAAAAAAAAfAAAAAAAAAEwAdQBjAGkAZABhACAAQwBv
AG4AcwBvAGwAZQAAADcxkAEAAAIHBAkCAgUCBAQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABD
AG8AdQByAGkAZQByAAAANSYAAAAAAgsGBAMFBAQCBId6AGEAAACACAAAAAAAAAD/AQEAAAAA
AFQAYQBoAG8AbQBhAAAAPQSQAQIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AFMAdABhAHIAUwB5AG0AYgBvAGwAAAA/NZABAAACBwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAA
AP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAOwaQAQIABQAAAAAAAAAAAAAAAAAA
AAAQAAAAAAAAAAAAAACAAAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAQgAEAEGIjBgA8NACAABo
AQAAAABbs3pmhLN6ZmarekYEACUAAACWIAAAvrkAAAEAbwAAAAQAg5CMAQAAliAAAL65AAAB
AG8AAACMAQAAAAAAACEDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAyNAAAEAAZAGQAAAAZAAAA5dkAAOXZAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA
AAAADDODUQDwEAAI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbAgAAAAAo8P8PAQAB
PwAA5AQAALMGAAD///9/AAAAAP///3////9/////f////3/MSQkA//8SAAAAAAAAADkAUgBl
AHMAbwB1AHIAYwBlACAAYQBuAGQAIABTAGUAcgB2AGkAYwBlACAATQBlAHQAYQBkAGEAdABh
ACAAZgBvAHIAIAB0AGgAZQAgAFYAaQByAHQAdQBhAGwAIABPAGIAcwBlAHIAdgBhAHQAbwBy
AHkAAAAAAAAACwBCAG8AYgAgAEgAYQBuAGkAcwBjAGgACABFAGQAIABTAGgAYQB5AGEAAAAA
AAAAAAAAAAAAAAAAAAAAAACQAAAABgAAACEAAAAAAAwAAQAMAAIADAADAAwABAAMAAUADAAG
AAwABwAMAAgADAAJAAwACgAMAAsADAAMAAwADQAMAA4ADAAPAAwAEAAMABEADAASAAwAEwAM
ABQADAAVAAwAFgAMABcADAAYAAwAGQAMABoADAAbAAwAHAAMAB0ADAAeAAwAHwAMACAADAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/
AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAALwBAAASAAAA
AQAAAJgAAAACAAAAoAAAAAMAAADkAAAABAAAAPAAAAAFAAAABAEAAAYAAAAQAQAABwAAABwB
AAAIAAAAMAEAAAkAAABEAQAAEgAAAFABAAAKAAAAbAEAAAsAAAB4AQAADAAAAIQBAAANAAAA
kAEAAA4AAACcAQAADwAAAKQBAAAQAAAArAEAABMAAAC0AQAAAgAAAOQEAAAeAAAAOgAAAFJl
c291cmNlIGFuZCBTZXJ2aWNlIE1ldGFkYXRhIGZvciB0aGUgVmlydHVhbCBPYnNlcnZhdG9y
eQAgAB4AAAABAAAAAGVzbx4AAAAMAAAAQm9iIEhhbmlzY2gAHgAAAAEAAAAAb2IgHgAAAAEA
AAAAb2IgHgAAAAsAAABOb3JtYWwuZG90AAAeAAAACQAAAEVkIFNoYXlhAHQAAB4AAAACAAAA
NAAgUx4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMABAAAAAAB45KwUAAABAAAAAAEw7EvqX
wwFAAAAAAApBs8GYwwFAAAAAACh63saYwwEDAAAAAQAAAAMAAACWIAAAAwAAAL65AAADAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAA
AAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmu
ZAEAACABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAAAIQAAAARAAAAjAAAABcA
AACUAAAACwAAAJwAAAAQAAAApAAAABMAAACsAAAAFgAAALQAAAANAAAAvAAAAAwAAAACAQAA
AgAAAOQEAAAeAAAAAgAAACAAbwADAAAAjAEAAAMAAABvAAAAAwAAAOXZAAADAAAAexAKAAsA
AAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAA6AAAAUmVzb3VyY2UgYW5k
IFNlcnZpY2UgTWV0YWRhdGEgZm9yIHRoZSBWaXJ0dWFsIE9ic2VydmF0b3J5AAwQAAACAAAA
HgAAAAYAAABUaXRsZQADAAAAAQAAAKwFAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAA
AQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAAZAUAAEgAAAADAAAABgBWAAMA
AAAhAAAAAwAAAAAAAAADAAAABQAAAB8AAAA1AAAAQwA6AFwAaABvAG0AZQBcAHMAZQBiAFwA
RABvAGMAdQBtAGUAbgB0AHMAXABVAEMARABcAEQAbwBjAHUAbQBlAG4AdABzAFwAVQBDAEQA
LQAyADAAMAAzADAAOQAyADIALgBkAG8AYwAAAAAAHwAAAAgAAABVAEMARAB0AHIAZQBlAAAA
AwAAAF8AEAADAAAAHgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFAAAAEMAOgBcAGgAbwBtAGUA
XABVAEMARABcAFUAQwBEAFwAagBzAFwAAAAfAAAAAQAAAAAAAAADAAAAKgBtAAMAAAAbAAAA
AwAAAAAAAAADAAAABQAAAB8AAAAfAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAdgBvAGEA
LgBuAGUAdAAvAEQAbwBjAHUAbQBlAG4AdABzAC8AAAAAAB8AAAABAAAAAAAAAAMAAAARAHsA
AwAAABgAAAADAAAAAAAAAAMAAAAFAAAAHwAAABwAAABtAGEAaQBsAHQAbwA6AHIAbwB5AEAA
YwBhAGMAcgAuAGMAYQBsAHQAZQBjAGgALgBlAGQAdQAAAB8AAAABAAAAAAAAAAMAAAB6AEgA
AwAAABUAAAADAAAAAAAAAAMAAAAFAAAAHwAAABkAAABtAGEAaQBsAHQAbwA6AGcAdAByAEAA
YQBzAHQALgBjAGEAbQAuAGEAYwAuAHUAawAAAAAAHwAAAAEAAAAAAAAAAwAAAB0AewADAAAA
EgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGwAAAG0AYQBpAGwAdABvADoAUABlAGQAcgBvAC4A
TwBzAHUAbgBhAEAAZQBzAGEALgBpAG4AdAAAAAAAHwAAAAEAAAAAAAAAAwAAADIABwADAAAA
DwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIwAAAG0AYQBpAGwAdABvADoAZgByAGEAbgBjAG8A
aQBzAEAAdgBpAHoAaQByAC4AdQAtAHMAdAByAGEAcwBiAGcALgBmAHIAAAAAAB8AAAABAAAA
AAAAAAMAAAAOAGgAAwAAAAwAAAADAAAAAAAAAAMAAAAFAAAAHwAAABsAAABtAGEAaQBsAHQA
bwA6AGoAYwBtAEAAYwBmAGEALgBoAGEAcgB2AGEAcgBkAC4AZQBkAHUAAAAAAB8AAAABAAAA
AAAAAAMAAAAUAC8AAwAAAAkAAAADAAAAAAAAAAMAAAAFAAAAHwAAAB0AAABtAGEAaQBsAHQA
bwA6AGEAbgBkAHIAZQBhAEAAcgBtAC4AaQBhAHMAZgAuAGMAbgByAC4AaQB0AAAAAAAfAAAA
AQAAAAAAAAADAAAAOgBOAAMAAAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAAAVAAAAbQBhAGkA
bAB0AG8AOgByAGcAbQBAAHIAbwBlAC4AYQBjAC4AdQBrAAAAAAAfAAAAAQAAAAAAAAADAAAA
FQAkAAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8AAAAeAAAAbQBhAGkAbAB0AG8AOgBuAG8A
cgBtAGEAbgBAAGEAcwB0AHIAbwAuAGcAbABhAC4AYQBjAC4AdQBrAAAAHwAAAAEAAAAAAAAA
AwAAAHQAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIwAAAG0AYQBpAGwAdABvADoA
ZABlAHIAcgBpAGUAcgBlAEAAbgBlAHcAYgA2AC4AdQAtAHMAdAByAGEAcwBiAGcALgBmAHIA
AAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUA
AAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAA
EwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAA
AAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAA
LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsA
AAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAA
SQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYA
AABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAA
ZAAAAGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEA
AAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAA
fwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwA
AACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAA
mgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcA
AACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAA
tQAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIA
AADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA
0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAN0A
AADeAAAA3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA
6wAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgA
AAD+////+gAAAPsAAAD8AAAA/QAAAP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAA
BgEAAAcBAAAIAQAACQEAAAoBAAALAQAADAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMB
AAAUAQAAFQEAABYBAAAXAQAAGAEAABkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAA
IQEAACIBAAAjAQAAJAEAACUBAAAmAQAAJwEAACgBAAApAQAAKgEAACsBAAAsAQAALQEAAC4B
AAAvAQAAMAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAAOQEAADoBAAA7AQAA
PAEAAD0BAAA+AQAAPwEAAEABAABBAQAAQgEAAEMBAABEAQAARQEAAEYBAABHAQAASAEAAEkB
AABKAQAASwEAAEwBAABNAQAATgEAAE8BAABQAQAAUQEAAFIBAABTAQAAVAEAAFUBAABWAQAA
VwEAAFgBAABZAQAAWgEAAFsBAABcAQAAXQEAAF4BAABfAQAAYAEAAGEBAABiAQAAYwEAAGQB
AABlAQAAZgEAAGcBAABoAQAAaQEAAGoBAABrAQAAbAEAAG0BAABuAQAAbwEAAHABAABxAQAA
cgEAAHMBAAB0AQAAdQEAAHYBAAB3AQAAeAEAAHkBAAB6AQAAewEAAHwBAAB9AQAAfgEAAH8B
AACAAQAAgQEAAIIBAACDAQAAhAEAAIUBAACGAQAAhwEAAIgBAACJAQAAigEAAIsBAACMAQAA
jQEAAI4BAACPAQAAkAEAAJEBAACSAQAAkwEAAJQBAACVAQAAlgEAAJcBAACYAQAAmQEAAJoB
AACbAQAAnAEAAJ0BAACeAQAAnwEAAKABAAChAQAAogEAAKMBAACkAQAApQEAAKYBAACnAQAA
qAEAAKkBAACqAQAAqwEAAKwBAACtAQAArgEAAK8BAACwAQAAsQEAALIBAACzAQAAtAEAALUB
AAC2AQAAtwEAALgBAAC5AQAAugEAALsBAAC8AQAAvQEAAL4BAAC/AQAAwAEAAMEBAADCAQAA
wwEAAMQBAADFAQAAxgEAAMcBAADIAQAAyQEAAMoBAADLAQAAzAEAAM0BAADOAQAAzwEAANAB
AADRAQAA0gEAANMBAADUAQAA1QEAANYBAADXAQAA2AEAANkBAADaAQAA2wEAANwBAADdAQAA
3gEAAN8BAADgAQAA4QEAAOIBAADjAQAA5AEAAOUBAADmAQAA5wEAAOgBAADpAQAA6gEAAOsB
AADsAQAA7QEAAO4BAADvAQAA8AEAAPEBAADyAQAA8wEAAPQBAAD1AQAA9gEAAPcBAAD4AQAA
+QEAAPoBAAD7AQAA/AEAAP0BAAD+AQAA/wEAAAACAAABAgAAAgIAAAMCAAAEAgAABQIAAAYC
AAAHAgAACAIAAAkCAAAKAgAACwIAAAwCAAANAgAADgIAAA8CAAAQAgAAEQIAABICAAATAgAA
FAIAABUCAAAWAgAAFwIAABgCAAAZAgAAGgIAABsCAAAcAgAAHQIAAB4CAAAfAgAAIAIAACEC
AAAiAgAAIwIAACQCAAAlAgAAJgIAACcCAAD+////KQIAACoCAAArAgAALAIAAC0CAAAuAgAA
LwIAADACAAAxAgAAMgIAADMCAAA0AgAANQIAADYCAAA3AgAAOAIAADkCAAA6AgAAOwIAADwC
AAA9AgAAPgIAAD8CAABAAgAAQQIAAEICAABDAgAARAIAAEUCAABGAgAARwIAAEgCAABJAgAA
SgIAAEsCAABMAgAATQIAAE4CAABPAgAAUAIAAFECAABSAgAAUwIAAFQCAABVAgAAVgIAAFcC
AABYAgAAWQIAAFoCAABbAgAAXAIAAF0CAABeAgAAXwIAAGACAABhAgAAYgIAAGMCAABkAgAA
ZQIAAGYCAABnAgAAaAIAAGkCAABqAgAAawIAAGwCAABtAgAAbgIAAG8CAABwAgAAcQIAAHIC
AABzAgAAdAIAAHUCAAB2AgAAdwIAAHgCAAB5AgAAegIAAHsCAAB8AgAAfQIAAH4CAAB/AgAA
gAIAAIECAACCAgAAgwIAAIQCAACFAgAAhgIAAIcCAACIAgAAiQIAAIoCAACLAgAAjAIAAI0C
AACOAgAAjwIAAJACAACRAgAAkgIAAJMCAACUAgAAlQIAAJYCAACXAgAAmAIAAJkCAACaAgAA
mwIAAJwCAACdAgAAngIAAJ8CAACgAgAAoQIAAKICAACjAgAApAIAAKUCAACmAgAApwIAAKgC
AACpAgAAqgIAAKsCAACsAgAArQIAAK4CAACvAgAAsAIAALECAACyAgAAswIAALQCAAC1AgAA
tgIAALcCAAC4AgAAuQIAALoCAAC7AgAAvAIAAL0CAAC+AgAAvwIAAMACAADBAgAAwgIAAMMC
AADEAgAAxQIAAMYCAADHAgAAyAIAAMkCAADKAgAAywIAAMwCAADNAgAAzgIAAM8CAADQAgAA
0QIAANICAADTAgAA1AIAANUCAADWAgAA1wIAANgCAADZAgAA/v///9sCAADcAgAA3QIAAN4C
AADfAgAA4AIAAOECAAD+////4wIAAOQCAADlAgAA5gIAAOcCAADoAgAA6QIAAP7////9////
/f////3////9/////f////3////xAgAA/v////7////+////////////////////////////
////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMA
AAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA0Gav5caYwwHzAgAAgAAAAAAAAABEAGEA
dABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAACgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAPkAAADmXQIAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAIAAFFiAQAAAAAAVwBvAHIAZABEAG8AYwB1AG0A
ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAA
BQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXvABAAAA
AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAANoCAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA
SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4gIAAAAQAAAAAAAAAQBDAG8AbQBwAE8A
YgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIA
AgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
agAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVu
dAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
--------------010506050500090703000306--

From owner-ucd@eso.org  Wed Oct 22 21:25:42 2003
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9MJLoKp022914
	for <ucd-outgoing@mercury.hq.eso.org>; Wed, 22 Oct 2003 21:21:50 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9MJLoew022913
	for ucd-outgoing; Wed, 22 Oct 2003 21:21:50 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9MJKHKp021778;
	Wed, 22 Oct 2003 21:20:17 +0200 (MEST)
Received: from nrcvicex1.hia.nrc.ca (nrcvicex1a.hia.nrc.ca [204.174.103.8])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9MJKFB1026989;
	Wed, 22 Oct 2003 21:20:16 +0200 (CEST)
Received: from frodo (cadc-nat.vic.hia.nrc.ca [204.174.103.36]) by nrcvicex1.hia.nrc.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VHHWQ495; Wed, 22 Oct 2003 12:20:12 -0700
Content-Type: text/plain;
  charset="iso-8859-1"
From: Patrick Dowler <patrick.dowler@nrc-cnrc.gc.ca>
Organization: National Research Council Canada
To: Norman Gray <norman@astro.gla.ac.uk>
Subject: Re: A suggested revision for UCDs
Date: Wed, 22 Oct 2003 12:19:29 -0700
User-Agent: KMail/1.4.3
Cc: ucd@ivoa.net, dm@ivoa.net, dal@ivoa.net
References: <Pine.LNX.4.44.0310221828540.12116-100000@ptolemy.astro.gla.ac.uk>
In-Reply-To: <Pine.LNX.4.44.0310221828540.12116-100000@ptolemy.astro.gla.ac.uk>
MIME-Version: 1.0
Message-Id: <200310221219.29068.patrick.dowler@nrc-cnrc.gc.ca>
X-Scanned-By: MIMEDefang 2.35
X-MIME-Autoconverted: from 8bit to quoted-printable by apollo.hq.eso.org id h9MJKFB1026989
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h9MJKoKp022446
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Patrick Dowler <patrick.dowler@nrc-cnrc.gc.ca>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Wednesday 22 October 2003 10:43, Norman Gray wrote:
> I'm sure it is this which causes some people (I'm thinking of Gerard
> Lemson and Pat Dowler) to gasp and, in their poster, pick out pos_eq_ra
> for special deprecation as incoherent.  If you believe that principled
> generation of UCD words would be a Good Thing (and that would probably
> be my prejudice), then I suspect that paths in (say) Gerard and Pat's
> model would be a good way to do it (do Gerard and Pat claim that every
> UCD word is thus expressible?). 

That particular example was chosen to show that the different parts of
the POS_EQ_RA_MAIN (UCD1) are quite different types of things with
different realtionships to the thing being described. In the data model,
POS is the "position" phenomenon, EQ is a particular ReferenceSystem,
RA is one component of a point (the type used to represent a position
in that ReferenceSystem). I still don't know that MAIN would belong in a
data model. It isn't "incoherent" so much as it includes some very different
kinds of things.

In the concept;property style of UCD2, I don't think it is inconsistent with
the data model we presented. The difference between UCD and DM is
that in a model one  explicitly states the relationship between the 
concept and the property, So, for example, in our DM we are
expliclty saying that the relationship between a position and the 
ReferenceSystem is a different relationship that between the position and the 
RA (a component of the data type/structure). UCD2 leaves the relationship 
implicit by having only one relationship: "propertyOf". Whether that's good 
or bad thing is an open issue.


-- 
Patrick Dowler
Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-0045
Canadian Astronomy Data Centre   | Centre canadien de donnees astronomiques
National Research Council Canada | Conseil national de recherches Canada
Government of Canada                  | Gouvernement du Canada
5071 West Saanich Road               | 5071, chemin West Saanich
Victoria, BC                                  | Victoria (C.-B.)


From owner-dm@eso.org  Wed Oct 22 22:37:38 2003
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9MKWnKp020616
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 22 Oct 2003 22:32:49 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9MKWnaU020615
	for dm-outgoing; Wed, 22 Oct 2003 22:32:49 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9MKWGKp020460;
	Wed, 22 Oct 2003 22:32:16 +0200 (MEST)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9MKWEs3010300;
	Wed, 22 Oct 2003 22:32:15 +0200 (CEST)
Received: from SARA (sara.cacr.caltech.edu [131.215.145.107])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9MKWDM9025960
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Wed, 22 Oct 2003 13:32:13 -0700
Message-ID: <01c501c398db$9ef8ef80$6b91d783@cacr.caltech.edu>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: <dm@ivoa.net>, <dal@ivoa.net>, <ucd@ivoa.net>
References: <3F96CE02.8020804@gsfc.nasa.gov>
Subject: Re: UCD changes on top of McGlynn's changes
Date: Wed, 22 Oct 2003 13:32:32 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

All:

>From now on, please do not cross-post UCD material to dm and dal.

Please send UCD-related posting to ucd@ivoa.net only.

Those of you on the other lists, please join the ucd list to continue
reading UCD material.

Thank You
Roy

--------
Caltech Center for Advanced Computing Research
roy@cacr.caltech.edu
626 395 3670

From owner-dal@eso.org  Thu Oct 23 23:37:02 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9NLZbjT028830
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 23 Oct 2003 23:35:37 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9NLZb31028829
	for dal-outgoing; Thu, 23 Oct 2003 23:35:37 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9NLZ0jT028670
	for <dal@ivoa.net>; Thu, 23 Oct 2003 23:35:00 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9NLYxs3009916
	for <dal@ivoa.net>; Thu, 23 Oct 2003 23:35:00 +0200 (CEST)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id h9NLYtE08296
	for <dal@ivoa.net>; Thu, 23 Oct 2003 15:34:55 -0600
Received: from oak (oak [146.88.1.137])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id h9NLYq72016868;
	Thu, 23 Oct 2003 15:34:52 -0600 (MDT)
Date: Thu, 23 Oct 2003 15:34:52 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net
Subject: DAL tutorial, WG minutes now available
Message-ID: <Pine.LNX.4.44.0310231529410.21114-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.2, required 7,
	SPAM_PHRASE_00_01, USER_AGENT_PINE)
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

The minutes from the DAL session at the October 16-17 interoperability
meeting are now online (thanks to Markus) at

    http://ivoa.net/twiki/bin/view/IVOA/InterOpOct2003DAL

Also, the slides for the DAL session from the October 12 ADASS VO tutorial
are now online at

    http://ivoa.net/twiki/bin/view/IVOA/VOSoftStdWorkshop03

Doug

From owner-dal@eso.org  Sat Oct 25 22:49:50 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9PKiP8N018130
	for <dal-outgoing@mercury.hq.eso.org>; Sat, 25 Oct 2003 22:44:25 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9PKiPbj018129
	for dal-outgoing; Sat, 25 Oct 2003 22:44:25 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9PKhB8N017553
	for <dal@ivoa.net>; Sat, 25 Oct 2003 22:43:11 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9PKhAs3017265
	for <dal@ivoa.net>; Sat, 25 Oct 2003 22:43:10 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id h9PKh5SU025084;
	Sat, 25 Oct 2003 14:43:05 -0600
Date: Sat, 25 Oct 2003 14:43:02 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: martin hill <mchill@dial.pipex.com>
cc: dal@ivoa.net
Subject: Re: FORTRAN access to .NET web services
In-Reply-To: <1066404376.3f900a183f648@netmail.pipex.net>
Message-ID: <Pine.LNX.4.44.0310251421260.2610-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Martin -

On Fri, 17 Oct 2003, martin hill wrote:

> I would be interested to know how the folks on this list feel about
> creating various web services.  I get the impression that people are happy
> creating http/get-based ones (like the NVO cone search is, and the SIAP
> and SSA will be) but feel a bit more wary of document-based ones (whether
> http/get-serviced or Remote-Procedure-Call serviced) and very sceptical
> about fully RPC-ones.  Yet I am told that in fact making WSDL-described
> RPC services is as easy or easier than http/get based ones. This was by
> software engineers though; I expect to get to grips with both over the
> next few weeks, and if people are interested I will report back to this
> group (and DAL) about how easy it was/wasnot.

The initial DAL services like Cone and SIA were based on HTTP GET to
make them simpler for people to deal with who have to write the code
"from the ground up".  Sure, SOAP-based web services can be easy to deal
with if you have invested in some Web Services platform like Axis or
.NET, but not if you developing from the ground up to, e.g., interface
VO services to a legacy system written in a compiled language.  Also,
web services technology has been evolving rapidly, certainly it has over
the past year.  Support for different languages can vary greatly, there
can still be interoperability issues, and so forth.  I think it is time
now to start providing web service versions of the DAL services, but it
would have been a mistake to push this too much a year ago.

In the longer term we probably want both document and RPC-based services.
Complex data like VOTable, ADQL, etc., are always going to be best
dealt with as documents.  Asynchronous messaging will also want to be
document based.  RPC using WSDL currently looks good for most simple web
services.  In many cases it will still be possible to retain HTTP GET as
a simplest-possible form of method invocation, for cases where only a few
simple parameters need to be passed in.  If we do this right, we should
be able to use any of these protocols to invoke the same service code.
Using the document-based approach for anything complicated should make
this much easier.

	- Doug

From owner-dal@eso.org  Sat Oct 25 23:53:31 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9PLmeM5028570
	for <dal-outgoing@mercury.hq.eso.org>; Sat, 25 Oct 2003 23:48:40 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9PLmeSn028569
	for dal-outgoing; Sat, 25 Oct 2003 23:48:40 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9PLm8M5028497
	for <dal@ivoa.net>; Sat, 25 Oct 2003 23:48:08 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9PLPPB1009386
	for <dal@ivoa.net>; Sat, 25 Oct 2003 23:25:25 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id h9PLPK8e026707;
	Sat, 25 Oct 2003 15:25:21 -0600
Date: Sat, 25 Oct 2003 15:25:17 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: martin hill <mchill@dial.pipex.com>
cc: dal@ivoa.net
Subject: Re: Data service types
In-Reply-To: <1066408171.3f9018eb50d37@netmail.pipex.net>
Message-ID: <Pine.LNX.4.44.0310251457040.2610-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Fri, 17 Oct 2003, martin hill wrote:

> One thing that didn't seem very clear from the meetings was what DAL was all 
> about.  We talked about the technicalities of two particular services: Images 
> and Spectra, but the rather larger set including stellar catalogues and other 
> databases of information wasn't considered (as if we didn't have enough to 
> talk about!).

The scope of DAL was a major topic of the May WG meeting in Cambridge.
The current thinking on the range of DAL services is summarized on the
DAL Wiki page and in the documents

    http://ivoa.net/internal/IVOA/IvoaDAL/IVOA-DAL-Jul03.pdf
    http://ivoa.net/internal/IVOA/IvoaDAL/DAL-Cambridge-Report.pdf

> Are we assuming just now that we are working on three services: images (SIAP 
> as cutout and 'as-stored'), spectra (SSA in early stages) and stellar 
> catalogues (as SkyNode2, being defined)?  Asan Astrogrid datacenter developer 
> I need to know who I should be talking to about making sure things are 
> compatible! Will & I have already been talking, but if the group feels that 
> SkyNode2 will be the *defining* interface for ADQL-querying VO datacenters, 
> and NVO Cone Searches for http/get VO datacenters, then we shall happily work 
> towards that (and provide input to that!).  If not we need to know!  We have 
> now 3 astrogrid datacenters running in various versions, and by Christmas 
> expect to have around 6-10 homogenous, so we need to know...! 

The plan for the next six months at least is OpenSkyNode for query-based
catalog access, retaining cone search for simple HTTP GET queries.
There will be a new version of SIA once the infrastructure (dataset
IDs, DM, UCD, VOTable, etc.) develops enough to make this wortwhile.
SSA of course is actively in development.  We need to experiment with
web services versions of all the DAL services.  This is likely to keep
us busy through next summer.

(Note SIAP can do generated image mosaics or arbitrary sky projections
as well as simple cutouts or static imagefiles).

> Also a suggestion that I think came up somewhere in the meeting, that we make
> the formats of the http/get urls similar.  This (might?) save having to use
> template urls (if that's what was meant by them).  For example, at the moment
> the SIAP uses a comma to separate RA/DEC, whereas NVO cone search specifies
> them explicitly. 

These are two different things.  SIA came after cone search, and the thinking
at the time was that a position "object" encoded as the POS string made sense
since this grouped the elements of the position, and provided a means for
generalizing POS in the future by adding more syntax.

The issue of templating URLs refers to the image access reference URL in SIA
(which is very different from the query URL).  The question here is whether
we want to parameterize the image access reference, rather than enumerate
every possible combination of parameters in the query response table.
An alternative might be to add a getImage method to the interface.

On the general issue of making the service interfaces more similar -
at some point we will want to update all these services to use the
latest technology.  At that time we can make them more uniform as well.
We don't want to be changing things too frequently, so this is probably
best done as an upgrade to all the services, once things have evolved
enough to make it worthwhile.

> Finally (really) I would also like to find out here what services people want
> to publish to the VO and some idea of the structure of that data, so we can
> build an overall picture of what the VO is likely to be serving.

As I say the current thinking on the range of services (data types) is
summarized in the documents above.  The structure of the data to be returned
is still being worked out.  For science-formatted data we are probably
looking mainly at some combination of FITS (at least for "image"-like data),
plus a more general XML encoding (e.g., in VOTable) of the VO data models
currently under development.  The idea is to define component data models
to characterize the attributes of a dataset, and model complex datasets
by aggregating these in some sort of XML container.  Where FITS is used,
the query response table can be used to return standard metadata (using
the component data models) describing the FITS-encoded object.

	- Doug

From owner-dal@eso.org  Sun Oct 26 00:05:10 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9PM0RM5029965
	for <dal-outgoing@mercury.hq.eso.org>; Sun, 26 Oct 2003 00:00:27 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9PM0RId029964
	for dal-outgoing; Sun, 26 Oct 2003 00:00:27 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9PLxrM5029817
	for <dal@ivoa.net>; Sat, 25 Oct 2003 23:59:53 +0200 (MEST)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9PLUas3011331
	for <dal@ivoa.net>; Sat, 25 Oct 2003 23:30:37 +0200 (CEST)
Received: from Ropy (dsl-pb-1504.linkline.com [64.30.223.60])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9PLUVM9010853
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Sat, 25 Oct 2003 14:30:32 -0700
Message-ID: <09f101c39b3f$3e79f210$6501a8c0@Ropy>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: "Doug Tody" <dtody@nrao.edu>, "martin hill" <mchill@dial.pipex.com>
Cc: <dal@ivoa.net>
References: <Pine.LNX.4.44.0310251421260.2610-100000@lepus.tuc.noao.edu>
Subject: Problem with standard NVO web services
Date: Sat, 25 Oct 2003 14:30:41 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

There is a problem looming with making our standard services into web
services.

For example cone search has three basic input keywords (RA, DEC, SR)
and some optional ones. However what we are really doing is saying
that these parameters must be in the request object -- *in addition to
others*.

When people implement a cone search, they often have extra, private
arguments. They want a single servlet or CGI to cover a number of
catalogs and circumstances. Clearly we do not write a separate piece
of code for each database query, we write the code once. The servlet
might be used by specifying which catalog (CAT=2mass), which version
of the catalog (VERSION=1.3), or other keywords in addition to the
"official" keywords in the specification.

In the GET specification, it is all very simple. We register our one
and only service (called "search") several times like this
http://blahblah.edu/search?CAT=2mass&
http://blahblah.edu/search?CAT=SDSS&VERSION=DR1&
http://blahblah.edu/search?CAT=Messier&

Now for my question: when we make SOAP versions of the Cone and SIAP
services, we will make WSDL files to describe the services. How many
WSDL files will there be? It could be
    -- one WSDL file because there is only one service
    -- many WSDL files, one for each catalog/version

What we really want is like the Java "interface" construct. Not a full
description, like WSDL, but saying it must support some specific
methods.

Cheers
Roy

--------
Caltech Center for Advanced Computing Research
roy@cacr.caltech.edu
626 395 3670

From owner-dal@eso.org  Sun Oct 26 15:41:05 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9QEaNM5019611
	for <dal-outgoing@mercury.hq.eso.org>; Sun, 26 Oct 2003 15:36:23 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9QEaNA9019610
	for dal-outgoing; Sun, 26 Oct 2003 15:36:23 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9QEZnM5019555
	for <dal@ivoa.net>; Sun, 26 Oct 2003 15:35:49 +0100 (MET)
Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9QEZmB1019996
	for <dal@ivoa.net>; Sun, 26 Oct 2003 15:35:49 +0100 (CET)
Received: from gnowee ([81.98.151.223]) by mta02-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20031026143548.XIXI8170.mta02-svc.ntlworld.com@gnowee>
          for <dal@ivoa.net>; Sun, 26 Oct 2003 14:35:48 +0000
From: "Tony Linde" <ael@star.le.ac.uk>
To: <dal@ivoa.net>
Subject: RE: Problem with standard NVO web services
Date: Sun, 26 Oct 2003 14:36:02 -0000
Organization: University of Leicester
Message-ID: <001401c39bce$7d47c690$0c01a8c0@gnowee>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <09f101c39b3f$3e79f210$6501a8c0@Ropy>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id h9QEaMM5019606
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Tony Linde" <ael@star.le.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

In a way this crosses with the Registry group in that whatever ways we find
of describing services have to be incorporated into the service description
in order to allow automated workflow engines to compose tasks into
workflows.

As I see it, any service is:

  inputs + options --> functions --> outputs

So what we need is:

1. a way to describe inputs and outputs. This should include some namespaced
data formats (eg VOTable) with some way of specifying backward compatibility
(eg input can be VOTable 1.1.3, 1.1.2 and 1.1.1 but not earlier); maybe just
a list of namespaces.

2. to use xsd data types for the options but need to include facility to
indicate hierarchy of options, eg if opt1=valA then opt2 and opt3 must be
specified but if opt1=valB then no more options.

3. some standard way to specify the function type(s?), eg data query
(includes cone search & sky node), image query etc; so a namespaced
enumerated list.

4. to describe how files are copied to the service for use as inputs and how
output files are retrieved: maybe a pointer to the local file transfer
service (with its own inputs, functions & outputs!); need handshaking
mechanism to determine most efficient common file transfer protocol where >1
supported.

All of the above then need to be incorporated into the registry description
of a service. A user constructing a workflow then just specifies that they
need a data query service with certain characteristics and the registry can
find relevant services. User chooses one, sets the options and plugs it into
the workflow, perhaps linking inputs to previous task outputs. The workflow
engine ensures matching file formats (and suggests converters if they don't
match), adds the appropriate file transfer services and user moves onto
specifying next task.

Cheers,
Tony. 

> -----Original Message-----
> From: owner-dal@eso.org [mailto:owner-dal@eso.org] On Behalf 
> Of Roy Williams
> Sent: 25 October 2003 22:31
> To: Doug Tody; martin hill
> Cc: dal@ivoa.net
> Subject: Problem with standard NVO web services
> 
> 
> There is a problem looming with making our standard services 
> into web services.
> 
> For example cone search has three basic input keywords (RA, 
> DEC, SR) and some optional ones. However what we are really 
> doing is saying that these parameters must be in the request 
> object -- *in addition to others*.
> 
> When people implement a cone search, they often have extra, 
> private arguments. They want a single servlet or CGI to cover 
> a number of catalogs and circumstances. Clearly we do not 
> write a separate piece of code for each database query, we 
> write the code once. The servlet might be used by specifying 
> which catalog (CAT=2mass), which version of the catalog 
> (VERSION=1.3), or other keywords in addition to the 
> "official" keywords in the specification.
> 
> In the GET specification, it is all very simple. We register 
> our one and only service (called "search") several times like 
> this http://blahblah.edu/search?CAT=2mass&
> http://blahblah.edu/search?CAT=SDSS&VERSION=DR1&
> http://blahblah.edu/search?CAT=Messier&
> 
> Now for my question: when we make SOAP versions of the Cone 
> and SIAP services, we will make WSDL files to describe the 
> services. How many WSDL files will there be? It could be
>     -- one WSDL file because there is only one service
>     -- many WSDL files, one for each catalog/version
> 
> What we really want is like the Java "interface" construct. 
> Not a full description, like WSDL, but saying it must support 
> some specific methods.
> 
> Cheers
> Roy
> 
> --------
> Caltech Center for Advanced Computing Research 
> roy@cacr.caltech.edu 626 395 3670
> 


From owner-dal@eso.org  Sun Oct 26 14:43:39 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id h9QDcgM5013808
	for <dal-outgoing@mercury.hq.eso.org>; Sun, 26 Oct 2003 14:38:42 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id h9QDcgIs013807
	for dal-outgoing; Sun, 26 Oct 2003 14:38:42 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id h9QDc9M5013745
	for <dal@ivoa.net>; Sun, 26 Oct 2003 14:38:09 +0100 (MET)
Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id h9QDc8B1024838
	for <dal@ivoa.net>; Sun, 26 Oct 2003 14:38:08 +0100 (CET)
Received: from nmail1.systems.pipex.net (localhost [127.0.0.1])
	by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id h9QDc2m7000949;
	Sun, 26 Oct 2003 13:38:02 GMT
Received: (from nobody@localhost)
	by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id h9QDc17T000948;
	Sun, 26 Oct 2003 13:38:01 GMT
Received: from 81.86.255.235 ( [81.86.255.235])
	as user abm36@dial.pipex.com by netmail.pipex.net with HTTP;
	Sun, 26 Oct 2003 13:38:01 +0000
Message-ID: <1067175481.3f9bce39ad2ef@netmail.pipex.net>
Date: Sun, 26 Oct 2003 13:38:01 +0000
From: martin hill <mchill@dial.pipex.com>
To: Roy Williams <roy@cacr.caltech.edu>
Cc: Doug Tody <dtody@nrao.edu>, dal@ivoa.net
Subject: Re: Problem with standard NVO web services
References: <Pine.LNX.4.44.0310251421260.2610-100000@lepus.tuc.noao.edu> <09f101c39b3f$3e79f210$6501a8c0@Ropy>
In-Reply-To: <09f101c39b3f$3e79f210$6501a8c0@Ropy>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: PIPEX NetMail (IMP3.1)
X-Originating-IP: 81.86.255.235
X-PIPEX-Username: abm36%dial.pipex.com
X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: martin hill <mchill@dial.pipex.com>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

As I understand it, each service has its own WSDL file.  What we need to do is
to ensure that certain standard methods exist on each service - this can perhaps
be verified by checking the WSDL when the service is registered, to see what
'standard' methods it provides.  

However we need to keep an eye on all the 'private' arguments - if these appear
often, then really they are 'common' arguments and we need to standardise them.
 But this can be done as an 'extended cone search' method provided as well as
the simple one, so that we preserve backward compatibility with the simple one.

Cheers,

Martin

Quoting Roy Williams <roy@cacr.caltech.edu>:

> There is a problem looming with making our standard services into web
> services.
> 
> For example cone search has three basic input keywords (RA, DEC, SR)
> and some optional ones. However what we are really doing is saying
> that these parameters must be in the request object -- *in addition to
> others*.
> 
> When people implement a cone search, they often have extra, private
> arguments. They want a single servlet or CGI to cover a number of
> catalogs and circumstances. Clearly we do not write a separate piece
> of code for each database query, we write the code once. The servlet
> might be used by specifying which catalog (CAT=2mass), which version
> of the catalog (VERSION=1.3), or other keywords in addition to the
> "official" keywords in the specification.
> 
> In the GET specification, it is all very simple. We register our one
> and only service (called "search") several times like this
> http://blahblah.edu/search?CAT=2mass&
> http://blahblah.edu/search?CAT=SDSS&VERSION=DR1&
> http://blahblah.edu/search?CAT=Messier&
> 
> Now for my question: when we make SOAP versions of the Cone and SIAP
> services, we will make WSDL files to describe the services. How many
> WSDL files will there be? It could be
>     -- one WSDL file because there is only one service
>     -- many WSDL files, one for each catalog/version
> 
> What we really want is like the Java "interface" construct. Not a full
> description, like WSDL, but saying it must support some specific
> methods.
> 
> Cheers
> Roy
> 
> --------
> Caltech Center for Advanced Computing Research
> roy@cacr.caltech.edu
> 626 395 3670
> 
> 


-- 
Martin Hill
07901 55 24 66
www.mchill.net

From owner-dal@eso.org  Sun Nov  2 15:36:58 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hA2EVfPx008150
	for <dal-outgoing@mercury.hq.eso.org>; Sun, 2 Nov 2003 15:31:41 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA2EVfbk008149
	for dal-outgoing; Sun, 2 Nov 2003 15:31:41 +0100 (MET)
Message-Id: <200311021431.hA2EVfbk008149@mercury.hq.eso.org>
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Date: Fri, 31 Oct 2003 18:43:26 +0100
From: Francois Bonnarel <bonnarel@aladin.u-strasbg.fr>
To: dal@ivoa.net
Subject: URL templating in SIAP
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@aladin.u-strasbg.fr>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hello Dal people,
   Two weeks after the interoperabilty meeting I come back to the URL
templating debate.

   If I remeber well there has been a couple of remarks about my
proposal in the DAL session in
strasbourg.
   a ) Use case: I have one , Suppose you want to write a nice
interface to a SIA service.
  In case a lot of URL refer to the same observation with only
"production" parameters differing
  from one to another, you would like to display this observation as
single to the user and propose
  him list of parameters. With SIA like it is today , once you have
recognized that a couple of lines
  refer to the same observation, you have to analyse all the URL to find
out all the differences: not
  really nice. That's why I think templating the URL could be usefull.
  b ) What was my (quick and dirty) proposal in two words:
         refer to the variable parameters as $"PARAMETER_NAME" in the
URL template
         the PARAMETER_NAME can be either:
                       an image genaration parameter as defined in
SIA 1.0
                        or a service specific parameter defined as a
"PARAM" element in the VOTable.
                        (possible values were strings separated by
blanck in my proposal in the character case
                            ---> could be variable length character
array in VOTable 2)
     c ) the first remark I heard was (Roy Williams) : Keep it simple
!!!
           I can understand that Roy, but Templating the URL could be
only an option, don't prevent a service
to write only URLs : should be undersood by the clients: an URL is a
template with no variable at all!
     d ) Use something cleaner like xpath (Markus Dolensky and others):
            Is it more easy to implement?
      e ) Do not template only the URL : Why not templating in Votable
Fields in general.
              What do the VOtable people think ?
      f ) Use Web service methods (getImage with parameters) instead of
URL templates (Doug Tody)
          ca you describe how it could work with an example Doug? can we
live with getImage as a real
          web service method and ImageQuery as simple URL? If ImageQuery
is a real Webservice method
          will the client see the VOtable anymore ?

Best regards
Fran=E7ois

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F-67000 Strasbourg (France)
Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb=
.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------
--------------25A062583FC65BFA5F0DD959
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Dal people,
<br>&nbsp;&nbsp; Two weeks after the interoperabilty meeting I come back
to the URL templating debate.
<p>&nbsp;&nbsp; If I remeber well there has been a couple of remarks about
my proposal in the DAL&nbsp;session in
<br>strasbourg.
<br>&nbsp;&nbsp; a ) Use case:&nbsp; I have one , Suppose you want to write
a nice interface to a SIA service.
<br>&nbsp; In case a lot of URL refer to the same observation with only
"production" parameters differing
<br>&nbsp; from one to another, you would like to display this observation
as single to the user and propose
<br>&nbsp; him list of parameters. With SIA like it is today , once you
have recognized that a couple of lines
<br>&nbsp; refer to the same observation, you have to analyse all the URL
to find out all the differences: not
<br>&nbsp; really nice. That's why I think templating the URL could be
usefull.
<br>&nbsp; b ) What was my (quick and dirty) proposal in two words:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; refer to the variable
parameters&nbsp; as $"PARAMETER_NAME" in the URL template
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the PARAMETER_NAME
can be either:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
an image genaration parameter as defined in SIA&nbsp;1.0
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or a service specific parameter defined as a "PARAM" element in the VOTable.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(possible values were strings separated by blanck in my proposal in the
character case
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
---> could be variable length character array in VOTable 2)
<br>&nbsp;&nbsp;&nbsp;&nbsp; c ) the first remark I&nbsp;heard was (Roy
Williams) : Keep it simple !!!
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I can
understand that Roy, but Templating the URL could be only an option, don't
prevent a service
<br>to write only URLs : should be undersood by the clients: an URL is
a template with no variable at all!
<br>&nbsp;&nbsp;&nbsp;&nbsp; d ) Use something cleaner like xpath (Markus
Dolensky and others):
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Is it more easy to implement?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; e ) Do not template only the URL : Why
not templating in Votable Fields in general.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
What do the VOtable people think ?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; f ) Use Web service methods (getImage
with parameters) instead of URL templates (Doug Tody)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ca you describe
how it could work with an example Doug?&nbsp;can we live with getImage
as a real
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; web service
method and ImageQuery as simple URL? If ImageQuery is a real Webservice
method
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will the client
see the VOtable anymore ?
<p>Best regards
<br>Fran&ccedil;ois
<br>&nbsp;
<pre>--&nbsp;
=====================================================================
Francois&nbsp;&nbsp;
Bonnarel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Observatoire Astronomique de Strasbourg
CDS (Centre de donnees&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11,
rue de l'Universite
astronomiques de Strasbourg)&nbsp;&nbsp;&nbsp; F-67000 Strasbourg (France)
Tel: +33-(0)3 90 24 24 11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WWW:
http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E-mail:
bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------</pre>
&nbsp;</html>
--------------25A062583FC65BFA5F0DD959--


From owner-dal@eso.org  Tue Nov  4 10:40:38 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hA49ajLd022015
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 4 Nov 2003 10:36:45 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA49ajHI022012
	for dal-outgoing; Tue, 4 Nov 2003 10:36:45 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hA49ZpLd021665
	for <dal@ivoa.net>; Tue, 4 Nov 2003 10:35:51 +0100 (MET)
Received: from ns2.u-strasbg.fr (ns2.u-strasbg.fr [130.79.200.3])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA49ZpB1011889
	for <dal@ivoa.net>; Tue, 4 Nov 2003 10:35:51 +0100 (CET)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns2.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id hA49ZosF017057
          for <dal@ivoa.net>; Tue, 4 Nov 2003 10:35:50 +0100 (CET)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id KAA12366;
	Tue, 4 Nov 2003 10:25:34 +0100 (MET)
Date: Tue, 4 Nov 2003 10:25:34 +0100 (MET)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200311040925.KAA12366@alinda.u-strasbg.fr>
To: bonnarel@aladin.u-strasbg.fr, dal@ivoa.net
Subject: Re: URL templating in SIAP
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from 8bit to quoted-printable by ns2.u-strasbg.fr id hA49ZosF017057
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id hA49aiLd021987
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Two additionals remarks: Idea e) was coming from Tom McGlynn
                         The proposal is also valid for SSA of course.
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Fri Nov  7 13:33:52 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hA7CWshm008864
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 7 Nov 2003 13:32:54 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA7CWsHv008863
	for dal-outgoing; Fri, 7 Nov 2003 13:32:54 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hA7CWKhm008650
	for <dal@ivoa.net>; Fri, 7 Nov 2003 13:32:20 +0100 (MET)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA7ANWs3009913
	for <dal@ivoa.net>; Fri, 7 Nov 2003 11:23:32 +0100 (CET)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id hA7ANWfs015911;
	Fri, 7 Nov 2003 11:23:32 +0100 (MET)
Received: from isou53 (isou53 [193.147.153.35])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with SMTP id hA7ANPBU020612;
	Fri, 7 Nov 2003 11:23:26 +0100 (MET)
Date: Fri, 7 Nov 2003 11:23:25 +0100
From: posuna@iso.vilspa.esa.es
To: dal@ivoa.net
Cc: Pedro.Osuna@esa.int, Jesus.Juan.Salgado@esa.int,
   Christophe.Arviset@esa.int, Alberto.Salama@esa.int
Subject: Simple access to ISO Spectra (+images) using ISO AIO in SIAP mode
Message-Id: <20031107112325.6ba31c84.posuna@iso.vilspa.esa.es>
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.9; sparc-sun-solaris2.8)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: posuna@iso.vilspa.esa.es
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear all,

at the Strasbourg IVOA meeting, we proposed a simple access to spectra
using a similar protocol to the SIAP. We have modified our system in
this line for accessing both ISO images and spectra in a SIAP-like way.

You can access an example at:

http://pma.standby.vilspa.esa.es:8080/aio/jsp/siap.jsp?id_target=M51&imageType=spectrum

(as usual in our system, a "format=html" can be input to see a
human-readable html page with the outputs)

We have included an "imagetype" parameter that can either be:

- spectrum
- image
- all

with obvious meanings.

By default (i.e., not including the imagetype), the answer will only be
images, fully SIAP compatible thus.


For the metadata information for the spectra in the VOTable output, this
is what we have put in:

- FIELD_ID="AXES" ucd=VOX:Spectrum_axes datatype="char" arraysize="*"
  
  This one indicates the axes names (in our case corresponding to the
  keyword names in our fits files) that ought to be used from the
  spectrum product  to do a display of the spectrum

- FIELD ID="UNITS" ucd="VOX:Spectrum_units" datatype="double"
  arraysize="*"

  This one indicates the units in which each of the axes is represented

- FIELD ID="FORMAT" ucd="VOX:Spectrum_Format
  

  This is a mime format for spectrum products in fits format.



As the aforementioned quantities would not be enough to be able to
overlap or represent different spectra coming from different
instruments, etc., we believe that we have found a solution by
introducing the following fields:


- FIELD ID="DIMEQ" ucd="VOX:Spectrum_dimeq" datatype="char"
  arraysize="*"/>

  This one represents the dimensional equation of the units in each of
  the axes. More on this later.
  The dimesnional equation is based on the fundamental dimesnionless
  quantities M,L,T,Q for Mass, Length, Time and Charge respectively.
  We represent the equation by, e.g: 

	MLT-2 

  where any number after the quantity means (exponential), i.e, the
  equation above should be read MLT^-2

  (this could be changed if it does not result too clear)  



- FIELD ID="SCALEQ" ucd="VOX:Spectrum_scaleq" datatype="char"
  arraysize="*"/>
  
  This one represents the scaling factor needed to transform the
  dimensional equation (dimensionless by definition) to the
  International System of Units. More on this later.

With these two quantities, one can always transform from any system of
units to other, and with the scaling factor it is possible to display
and overlay diffrent scaled spectra. We give some explanation of what we
mean below with a working example.



--------------------------------------------
Use of dimensional equation for the metadata
--------------------------------------------

Our data fluxes, in the case of LWS, are given in "w/cm^2/um", whereas
the data for SWS are given in Jy.

We thus need a way to convert from one to the other. Let's try
to convert the LWS spectrum units (w/cm^2/s) to the SWS spectrum units
(in Jy) and then display both in the same browse tool.   

According to our server, the SWS flux (in Jy) dimensional equation is:

[SWS] = MT-2

and the LWS (w/cm^2/um) dimensional equation is:

[LWS] = MLT-3


So, to represent one with respect to the other, we will have to divide
both dimensional equations:

[SWS]     MT-2
----- = ------- = LT 
[LWS]   ML-1T-3


as the only quantities we can use in the transformation are those coming
from the conversion between "wavelength" and "frequency", to go from one
to the other we will have to use a combination of "LAMBDA" and "c"
(wavelength and light velocity). So the above equation has to be equal
to:

LT = [LAMBDA]^n [c]^m  = L^n [LT-1]^m = L^(n+m) T^-m


Which means (by equaling the exponents):

n+m=1
-m=1

and thus:

m=-1
n=2



so to go from SWS spectrum to LWS one, we will have to multiply by:

[LAMBDA]^2/[c]

which is as expected from physical reasonings (please check page 82 of
the ISO Handbook - Vol 1. MISSION OVERVIEW at
http://www.iso.vilspa.esa.es/manuals/HANDBOOK/I/gen_hb/).


(In case the above 2x2 system of equations is not solvable, then the two
spectra could not be comparable).




This would give the dimensionless equation. To get to International
System units, we would simply have to do:


FLUX(SWS units) = Flux(LWS units) [LAMBDA]^2 [c]^-1 [SWS scale] / [LWS
scale]

FLUX(SWS units)  = Flux(LWS units) [LAMBDA]^2 [c]^-1 10^-26 10^-10
                 = 10^-36 Flux(LWS units) [LAMBDA]^2 [c]^-1


   
where obviously, LAMBDA and c should be given in international system
units (LAMBDA in International Units is deducible from the LAMBDA given
in the spectrum times its Spectrum_scaleq factor).


This procedure might look cumbersome, but once the algorithm is
understood a computer can do it without problems.

------------------------------------------------------------------------


We believe this way of presenting metadata in this type of simple access
a la SIAP makes it easy to access our spectra and might be used for
other spectra as well, at least for those in fits format. 

This does not clash in our view with the more complicated and general
SSAP work which is going thoroughly on, but simply tries to give access
to our spectra products in an easy way.


Please let us know if you have any comments.

Best regards,
Pedro Osuna and Jesus Salgado.







-- 

Pedro Osuna Alcalaya


SOFTWARE Development Group
XMM-Newton Science Archive				
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314  				

European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727 
E-28080 Villafranca del Castillo
MADRID - SPAIN


From owner-dal@eso.org  Fri Nov  7 16:04:23 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hA7F3Phm001774
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 7 Nov 2003 16:03:25 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hA7F3P2c001760
	for dal-outgoing; Fri, 7 Nov 2003 16:03:25 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hA7F2ghm001565
	for <dal@ivoa.net>; Fri, 7 Nov 2003 16:02:42 +0100 (MET)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hA7F2fs3016759
	for <dal@ivoa.net>; Fri, 7 Nov 2003 16:02:41 +0100 (CET)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id hA7F2Dl1020700;
	Fri, 7 Nov 2003 08:02:14 -0700
Date: Fri, 7 Nov 2003 08:02:12 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: posuna@iso.vilspa.esa.es
cc: dal@ivoa.net, <Pedro.Osuna@esa.int>, <Jesus.Juan.Salgado@esa.int>,
   <Christophe.Arviset@esa.int>, <Alberto.Salama@esa.int>
Subject: Re: Simple access to ISO Spectra (+images) using ISO AIO in SIAP
 mode
In-Reply-To: <20031107112325.6ba31c84.posuna@iso.vilspa.esa.es>
Message-ID: <Pine.LNX.4.44.0311070759030.2610-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Pedro -

This is great to see, and will help our SSA prototyping efforts.
I was able to execute a query and download the spectrum, getting
a FITS binary table back.

	- Doug


On Fri, 7 Nov 2003 posuna@iso.vilspa.esa.es wrote:

> Dear all,
> 
> at the Strasbourg IVOA meeting, we proposed a simple access to spectra
> using a similar protocol to the SIAP. We have modified our system in
> this line for accessing both ISO images and spectra in a SIAP-like way.
> 
> You can access an example at:
> 
> http://pma.standby.vilspa.esa.es:8080/aio/jsp/siap.jsp?id_target=M51&imageType=spectrum
> 
> (as usual in our system, a "format=html" can be input to see a
> human-readable html page with the outputs)
> 
> We have included an "imagetype" parameter that can either be:
> 
> - spectrum
> - image
> - all
> 
> with obvious meanings.
> 
> By default (i.e., not including the imagetype), the answer will only be
> images, fully SIAP compatible thus.

From owner-dal@eso.org  Fri Nov 14 17:51:50 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAEGp84i005581
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 14 Nov 2003 17:51:08 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAEGp84I005578
	for dal-outgoing; Fri, 14 Nov 2003 17:51:08 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hAEGoV4i005467
	for <dal@ivoa.net>; Fri, 14 Nov 2003 17:50:31 +0100 (MET)
Received: from tonto (CM-lconC2-177-66.cm.vtr.net [200.83.177.66])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAEGoSs3019404
	for <dal@ivoa.net>; Fri, 14 Nov 2003 17:50:29 +0100 (CET)
Received: from mail by tonto with local (Exim 3.36 #1 (Debian))
	id 1AKh9H-0000sR-00
	for <dal@ivoa.net>; Fri, 14 Nov 2003 13:50:19 -0300
Delivered-To: postmaster@tonto
Received: from localhost (127.0.0.1) by tonto with POP3 for
  <postmaster@tonto>; 14 Nov 2003 16:50:19 -0000
Received: from ctiosz.ctio.noao.edu (ctiosz.ctio.noao.edu [139.229.2.71])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAEGsMf17448
	for <andrew@acooke.org>; Fri, 14 Nov 2003 08:54:23 -0800
Received: from ctiosz.ctio.noao.edu (localhost [127.0.0.1])
	by ctiosz.ctio.noao.edu (8.12.8/8.12.8) with ESMTP id hAEGlpnQ015864
	for <andrew@acooke.org>; Fri, 14 Nov 2003 13:47:51 -0300
Received: (from andrew@localhost)
	by ctiosz.ctio.noao.edu (8.12.8/8.12.8/Submit) id hAEGlpA3015862
	for andrew@acooke.org; Fri, 14 Nov 2003 13:47:51 -0300
Received: from ctios2.ctio.noao.edu (ctio.noao.edu [139.229.2.3])
	by ctiosz.ctio.noao.edu (8.12.8/8.12.8) with ESMTP id hAEGlonQ015839
	for <andrew@ctiosz.ctio.noao.edu>; Fri, 14 Nov 2003 13:47:50 -0300
Received: from noao.edu (noao.edu [140.252.1.54])
	by ctios2.ctio.noao.edu (8.9.3+Sun/8.9.3) with SMTP id NAA17078
	for <acooke@ctio.noao.edu>; Fri, 14 Nov 2003 13:47:48 -0300 (CLST)
Received: from apollo.hq.eso.org ([134.171.42.42] verified)
  by noao.edu (CommuniGate Pro SMTP 4.1.5)
  with ESMTP id 9535421; Fri, 14 Nov 2003 09:47:47 -0700
Received: from mercury.hq.eso.org (mercury.hq.eso.org [134.171.7.20])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id hAEGlKB1026783;
	Fri, 14 Nov 2003 17:47:20 +0100 (CET)
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAEGkT4i004663
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 14 Nov 2003 17:46:29 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAEGkTEF004662
	for dal-outgoing; Fri, 14 Nov 2003 17:46:29 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hAEGju4i004514
	for <dal@ivoa.net>; Fri, 14 Nov 2003 17:45:56 +0100 (MET)
Received: from milkyway.gsfc.nasa.gov (lheapop.gsfc.nasa.gov [128.183.16.62])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAEGjsB1026759
	for <dal@ivoa.net>; Fri, 14 Nov 2003 17:45:55 +0100 (CET)
Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68])
	by milkyway.gsfc.nasa.gov (8.12.10/8.12.10) with ESMTP id hAEGjoXU028007
	for <dal@ivoa.net>; Fri, 14 Nov 2003 11:45:52 -0500
Message-ID: <3FB506BF.4040001@lheapop.gsfc.nasa.gov>
Date: Fri, 14 Nov 2003 11:45:51 -0500
From: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Templating in VOTable
References: <200311132230.XAA00643@alinda.u-strasbg.fr>
In-Reply-To: <200311132230.XAA00643@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Scanned-By: MIMEDefang 2.35
X-MIME-Autoconverted: from 8bit to quoted-printable by milkyway.gsfc.nasa.gov id hAEGjoXU028007
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id hAEGkS4i004659
X-Loop: from ctio
Status:   
X-MIME-Autoconverted: from 8bit to quoted-printable by rocky.hq.eso.org id hAEGoSs3019404
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id hAEGp64i005563
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Francois suggested that this might be of interest
to the DAL group, and so I've posted it there.
Note that the suggestion below is really just
a sketch of what might be possible, not a real
proposal.
	Tom McGlynn


Francois Bonnarel wrote:

> Dear Tom,
>     At the DAL meeting in Strasbourg , when I proposed to template
> the URL in the acref in SIA, your answer was to propose a templating
> in VOTable cells in general, as a wider solution. I rediscussed this
> recently with François Ochsenbein. We are interested. have you an idea
> of how it could work?
> Cheers
> 
> 
> François
> 


Hi Francois,

Below I'll sketch out a couple of ideas, but the basic concern I have
is that templates are potentially useful in many contexts, so
that whatever we do should probably not be associated with
a single protocol (e.g., SIA), but done more generically.

One approach would be for the VO to assert that all data transmission
protocols at the VO inherit from some base protocol and that templating
would be addressed at this highest level.  E.g., this high level
protocol would allow any XML file to be transferred either as a standard
XML file, or as a combination of a base XML file and an XSLT script.
The script would be run on the base file to produce the standard
file.  This would support templating and a lot more, and leverages
existing standards.  However I'm not sure that we'll be able to
retrofit this into existing protocols.

The other place where it would seem natural to define the templating
mechanism is for VOTables themselves.   Then it naturally transfers
to all protocols that return VOTables.  I'm sure there are
better ways, but here's a suggestion for how it might
look:

    Define a new element <SUB> which is allowed inside
the <RESOURCE> and <TABLE> elements.
<SUB> has KEY and VALUE elements (or attributes I don't really
care).  In any <TD> element that follows a <SUB>, a string
of the form ${nnnn} is replaced by the value of the last SUB
element with the key nnnn (or left unchanged if there
is no such element). This addresses the repetition of long URLs
so that they can be specified once and then given as a short string
Only the parameters that change need be specified fully on each line.

However you were also concerned about the multiplication
of rows required when we had lots of potentially varying
parameters.  We can expand the idea above to handle this.
E.g., let's have:

     <SUB key=baseurl>
         <VALUE>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?</VALUE>
     </SUB>
     <SUB group=form key=format>
         <VALUE>GIF</VALUE>
         <VALUE>FITS</VALUE>
         <VALUE>TXT</VALUE>
     </SUB>
     <SUB group=form key=query>
         <VALUE>QUICKLOOK</VALUE>
         <VALUE>DATA</VALUE>
         <VALUE>TEXT</VALUE>
     </SUB>
     <SUB key=survey>
         <VALUE> DSS </VALUE>
         <VALUE> 2MASS-K </VALUE>
         <VALUE> ROSAT</VALUE>
     </SUB>

Now an SIA result from SkyView might have a single line
where the URL and format columns would be:

     <TD> ${baseURL}SURVEY=${SURVEY}&RETURN=${query}&VCOORD=32.13,12.97 </TD><TD>${format}</TD>

There are four different substitutions going on here.  The first is just
the base URL that we had before, but we now also have three other substitutions
which each have three values.  The idea (and perhaps this goes too far), is that
we could allow this to expand to multiple rows in the output.
This example row would be intended to expand to 9 rows.  Since
the format and query fields have the same group key, they are varied together
and must have the same number of elements.  Thus we always generate lines
with where the format is GIF associated with the query being QUICKLOOK.
However the survey key does not have the same group as the others so it
we vary it independently.  So after substitution we get:

      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=DSS&RETURN=QUICKLOOK&VCOORD=32.13,12.97 </TD><TD>GIF</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=DSS&RETURN=DATA&VCOORD=32.13,12.97 </TD><TD>GIF</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=DSS&RETURN=TEXT&VCOORD=32.13,12.97 </TD><TD>GIF</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=2MASS-K&RETURN=QUICKLOOK&VCOORD=32.13,12.97 </TD><TD>GIF</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=2MASS-K&RETURN=DATA&VCOORD=32.13,12.97 </TD><TD>FITS</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=2MASS-K&RETURN=TEXT&VCOORD=32.13,12.97 </TD><TD>TXT</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=ROSAT&RETURN=QUICKLOOK&VCOORD=32.13,12.97 </TD><TD>GIF</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=ROSAT&RETURN=DATA&VCOORD=32.13,12.97 </TD><TD>FITS</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=ROSAT&RETURN=TEXT&VCOORD=32.13,12.97 </TD><TD>TXT</TD>
      <TD>http://skyview.gsfc.nasa.gov/cgi-bin/nnskcall?SURVEY=DSS&RETURN=QUICKLOOK&VCOORD=32.13,12.97 </TD><TD>GIF</TD>

Any other rows in the table are duplicated. [I left the VCOORD stuff out of the
base URL since I wasn't being very smart, but it does help illustrate
how explicitly specified and templated parameters interact.]

There are probably better ideas for the syntax here, but something
along these lines is what I had in mind.  Of course it's essential
that a user be able to request that the data be expanded before transmission.

This kind of approach which uses a custom substitution scheme is probably
easier to incorporate into existing protocols, but it's less general
than the kind of XSLT based approach.  That's not entirely a
disadvantage.  One can probably make the input files
quite incomprehensible with the first approach.

Just to reiterate in closing, I like  the idea
of templating, I'd just like to see it in a broader context
than the SIA service.

	Regards,
	Tom





From owner-dal@eso.org  Fri Nov 14 19:45:49 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAEIj64i029226
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 14 Nov 2003 19:45:06 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAEIj6br029225
	for dal-outgoing; Fri, 14 Nov 2003 19:45:06 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hAEIiY4i029129
	for <dal@ivoa.net>; Fri, 14 Nov 2003 19:44:34 +0100 (MET)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAEIiWB1029632
	for <dal@ivoa.net>; Fri, 14 Nov 2003 19:44:33 +0100 (CET)
Received: from SARA (sara.cacr.caltech.edu [131.215.145.107])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAEIiVM9006073
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <dal@ivoa.net>; Fri, 14 Nov 2003 10:44:31 -0800
Message-ID: <0aec01c3aadf$7135b540$6b91d783@cacr.caltech.edu>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: <dal@ivoa.net>
Subject: Re: Templating in VOTable
Date: Fri, 14 Nov 2003 10:45:14 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Francois and Tom

I have been using SIAP extensively for the Atlasmaker project. Extensively
in terms of quantity (several TB in thousands of calls), although only three
actual services. However, my project can read ANY properly built SIAP.

The template method seems backwards. A request is made, then the response is
all the possible requests you can make! Why not simply add keywords to the
specific Skyview SIAP so that you can specify format, size, center
coordinates, etc? Those non-standard keywords will then be defined in the
registry along with the possible values of BANDPASS, etc. If you don't use
the extra keywords, then you get a default.

The templated access as written seems pretty complex. It would mean for me a
lot of non-XML syntax and semantics to absorb, then new code to be built.

My collaborators in San Diego have built a service to return arbitrary FITS
cutouts from the large (23500x23500) DPOSS images. I have asked them to
SIMPLIFY the interface, so that you can ask for the image to be chopped into
1, 4, 16, or 64 subimages. Now we have a normal SIAP service that has one
extra parameter. The simple interface is wanted, not the sophisticated
one -- at least by me.

Can I ask to see the use cases and requirements that justify the templated
access protocol? Who is asking for it?

Roy

--------
Caltech Center for Advanced Computing Research
roy@cacr.caltech.edu
626 395 3670


From owner-registry@eso.org  Fri Nov 21 00:24:20 2003
Return-Path: <owner-registry@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAKNNCh0006768
	for <registry-outgoing@mercury.hq.eso.org>; Fri, 21 Nov 2003 00:23:12 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAKNNC6R006767
	for registry-outgoing; Fri, 21 Nov 2003 00:23:12 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-registry@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hAKNMch0006638;
	Fri, 21 Nov 2003 00:22:38 +0100 (MET)
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAKNMbB1021575;
	Fri, 21 Nov 2003 00:22:37 +0100 (CET)
Received: from dial.pipex.com (81-86-239-97.dsl.pipex.com [81.86.239.97])
	by shockwave.systems.pipex.net (Postfix) with ESMTP id 129051C0044B;
	Thu, 20 Nov 2003 23:22:36 +0000 (GMT)
Message-ID: <3FBD4CBE.2030008@dial.pipex.com>
Date: Thu, 20 Nov 2003 23:22:38 +0000
From: Martin Hill <mchill@dial.pipex.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dm@ivoa.net, dal@ivoa.net, registry@ivoa.net
Subject: [Quality] another can of worms
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-registry@eso.org
Precedence: bulk
Reply-To: Martin Hill <mchill@dial.pipex.com>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi all

I've been wondering what to do about quality, and how to describe it.

We have a general one - if we allow anyone to publish to the VO, how do 
we describe a datacenter's quality?  There are datacenters setup for a 
sky survey, with all the processing involved that has been set up by 
teams of astronomers (presumably?) double checking each other. And there 
is data published by a small group or an individual so that people can 
access it, but which has not gone through such a rigorous set of tests. 
  We don't really want a general query to the registry returning both as 
'equals value' (or do we?).

We also have a smaller scale one - each item of data may need to be 
marked.  For example, a sky survey may have items that have been marked 
as 'possibly satellite track' or 'instrument feature' (is that the word? 
such as diffraction spikes?)

It's surfaced occasionally in some groups as a 'placeholder' but doesn't 
seem to have been dealt with in itself.  Has anyone come up with a 
framework (I can't find a general one)?  If not, where do we start?  Is 
a 'placeholder' sufficient for all three groups (dal/dm/registry) to 
start with?

I've posted this across all three groups for discussions about quality 
and what it means/implies on a large scale. Obviously it should split 
down when it becomes more specific!  Such as whether [Quantity] should 
include [Quality] as well as [Error]; and whether this is the same 
[Quality] as that attached to a dataset... :-)

Cheers,

Martin

-- 
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org

From owner-dal@eso.org  Fri Nov 21 23:00:43 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hALLxsh0002824
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 21 Nov 2003 22:59:54 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hALLxsFJ002823
	for dal-outgoing; Fri, 21 Nov 2003 22:59:54 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hALLwlh0002570;
	Fri, 21 Nov 2003 22:58:47 +0100 (MET)
Received: from po0.wam.umd.edu (po0.wam.umd.edu [128.8.10.162])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hALLwjs3024247;
	Fri, 21 Nov 2003 22:58:46 +0100 (CET)
Received: from gsfc.nasa.gov (atlas.astro.umd.edu [129.2.14.14])
	by po0.wam.umd.edu (8.12.10/8.12.10) with ESMTP id hALLwd4J020647;
	Fri, 21 Nov 2003 16:58:39 -0500 (EST)
Message-ID: <3FBE88D6.8010407@gsfc.nasa.gov>
Date: Fri, 21 Nov 2003 16:51:18 -0500
From: Ed Shaya <Edward.J.Shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin Hill <mchill@dial.pipex.com>
CC: dm@ivoa.net, dal@ivoa.net, registry@ivoa.net
Subject: Re: [Quality] another can of worms
References: <3FBD4CBE.2030008@dial.pipex.com>
In-Reply-To: <3FBD4CBE.2030008@dial.pipex.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ed Shaya <Edward.J.Shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000



Martin Hill wrote:

> Hi all
>
> I've been wondering what to do about quality, and how to describe it.
>
> We have a general one - if we allow anyone to publish to the VO, how 
> do we describe a datacenter's quality?  There are datacenters setup 
> for a sky survey, with all the processing involved that has been set 
> up by teams of astronomers (presumably?) double checking each other. 
> And there is data published by a small group or an individual so that 
> people can access it, but which has not gone through such a rigorous 
> set of tests.  We don't really want a general query to the registry 
> returning both as 'equals value' (or do we?).

I share your worry about inaccurate in error bars slipping in. But, if 
we try to fully answer this question we will be embroiled in politics 
and the NSF has funded the NVO project with the hope that it would not 
be 100% politics.  We should focus on more technical issues.  The most 
expedient thing to do is to allow all to publish and trust error bars.  
Creating a system that can properly handle data with error bars is both 
novel and comlicated enough. 

Query responses should carry information on the origin of any data 
unless explicitly told not to.  Then as a separate effort (perhaps IAU 
backed)  examine rational ways to censure data.  We should keep in mind 
when developing metadata standards that we have sufficient information 
to create automated means of hunting for an eliminating poor data or 
poor quality determinations.

>
> We also have a smaller scale one - each item of data may need to be 
> marked.  For example, a sky survey may have items that have been 
> marked as 'possibly satellite track' or 'instrument feature' (is that 
> the word? such as diffraction spikes?)
>
One can provide for a Note to be added at any level down to the 
individual pixel.  A single Note can be referenced many times for reuse 
in a document.  A Note can carry  a pixel list that indicates where in 
the data it applies.   This concept should be carried into the Data 
Model in general.  Notes can hold any string but it could be mixed with 
elements.  The Metadata group could perhaps work on some standard 
elements for common notes like <cosmic ray hit/>, <cirrus/>, 
<telescopeBumbedtheConsole/> or <diffraction spike />

>
>

From owner-dal@eso.org  Tue Nov 25 13:13:12 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAPCCCuF021747
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 25 Nov 2003 13:12:12 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAPCCB8o021745
	for dal-outgoing; Tue, 25 Nov 2003 13:12:11 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAPCCAnp021738
	for <dal@ivoa.net>; Tue, 25 Nov 2003 13:12:10 +0100 (MET)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hAPCCAt17359
	for <dal@ivoa.net>; Tue, 25 Nov 2003 13:12:10 +0100 (MET)
Message-ID: <3FC3470D.2070103@eso.org>
Date: Tue, 25 Nov 2003 13:11:57 +0100
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Re: spectral WCS in FITS
References: <004501c3b130$eccb5140$b4324d0c@euttq>
In-Reply-To: <004501c3b130$eccb5140$b4324d0c@euttq>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

It all boils down to the question:

Is there a way to express a vector in a single cell of a FITS ASCII table, right?

If so, FITS BINTABLE structure proposed by Greisen et al. can be mapped to 
ASCII tables. And consequently XSLT can be used to transform between ASCII 
table and VOTable formats.

I don't know the answer, but at least it should clarify what we are looking for.

Markus


Robert Hanisch wrote:
> As many of you know, substantial progress has been made in the last year or
> two on standardizing the representation of world coordinate systems in FITS.
> Two papers have been published thus far, describing both a general formalism
> and specific implementation for celestial coordinates.  A third paper is in
> near-final form, describing spectral coordinate systems.  I was asked to
> read and comment on this paper, and would like to draw wider attention to it
> and raise a concern I have to see if it is shared by others in the VO
> development community.
> 
> You may find the latest draft of this paper here:
> 
>     http://www.aoc.nrao.edu/~egreisen/scs_112103.ps.gz
>     http://www.aoc.nrao.edu/~egreisen/scs_112103.ps
> 
> 
> My concern is that the paper provides no simple FITS ASCII table
> representation for spectra in which the wavelength scale is given by an
> explicit list of values, each with an associated flux.  Rather, it supports
> a wavelength scale look-up using a FITS BINTABLE extension, and only allows
> the wavelength and flux arrays to be stored as vectors in single cells.
> There are advantages to this approach in terms of efficiency and robustness.
> However, looking ahead to the imminent development of a Simple Spectral
> Access Protocol, I would expect that a basic encoding scheme for spectra
> would be a VOTable with columns for wavelength, flux, error, etc.  It seems
> to me that this VOTable should be as close in structure as a FITS
> representation as possible, to the point where we should be able to
> translate the VOTable to FITS with an XML style sheet.  Also, there is much
> extant software that reads and writes spectra in even simpler ASCII text
> files, with tab- or space-delimited columns and very simple column headers.
> Thus, in the interest of the simplest possible interoperability for spectral
> data, I have suggested to the authors of the FITS spectral WCS paper to
> consider adding a FITS ASCII table option for the tabular form of a
> spectrum.  So far I've been told that there is "no way in which it can be
> implemented."  I do not believe this statement, but would like to hear from
> others in the VO community before pressing the case further.
> 
> Thanks,
> Bob

From owner-dal@eso.org  Tue Nov 25 13:43:45 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAPCh4uF001998
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 25 Nov 2003 13:43:04 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAPCh4SD001997
	for dal-outgoing; Tue, 25 Nov 2003 13:43:04 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hAPCgVuF001829;
	Tue, 25 Nov 2003 13:42:31 +0100 (MET)
Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAPCgUs3003979;
	Tue, 25 Nov 2003 13:42:30 +0100 (CET)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1AOcWU-000L6n-FT; Tue, 25 Nov 2003 12:42:30 +0000
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1AOcWU-0006GU-00; Tue, 25 Nov 2003 12:42:30 +0000
Date: Tue, 25 Nov 2003 12:42:30 +0000 (GMT)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Markus Dolensky <Markus.Dolensky@eso.org>
cc: dal@ivoa.net
Subject: Re: spectral WCS in FITS
In-Reply-To: <3FC3470D.2070103@eso.org>
Message-ID: <Pine.GSO.4.53.0311251235400.5200@adikia>
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1AOcWU-000L6n-FT*G29WEKjFfds*
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Dear All,

I am not sure if I agree with Bob's point, as it seems to me that part of
the purpose of VOTable is to do things which it is more suited to than
FITS, and to provide extra metadata where FITS is inadequate (i.e. the
bulk of existing data which have unfortunately for one reason or another
not fully complied with standards even where they existed...).  However it
might be relevant to look at the tool for importing data including FITS
and plain ascii TSV, CSV etc. tables into VOTable which Pallavi Kulkani of
VO India is developing alongside CDS and VOPlot.  Also, what is being
developed for the ALMA archive? Andreas Wisnec mentioned how they are
using VOTable to store FITS metadata.  This seems to me more efficient
than trying to make FITS do everything.

Put another way, there is certainly the need for a standard, but that
should be independent of how it is implimented to describe FITS, VOTable,
ascii or whatever.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).


On Tue, 25 Nov 2003, Markus Dolensky wrote:

> It all boils down to the question:
>
> Is there a way to express a vector in a single cell of a FITS ASCII table, right?
>
> If so, FITS BINTABLE structure proposed by Greisen et al. can be mapped to
> ASCII tables. And consequently XSLT can be used to transform between ASCII
> table and VOTable formats.
>
> I don't know the answer, but at least it should clarify what we are looking for.
>
> Markus
>
>
> Robert Hanisch wrote:
> > As many of you know, substantial progress has been made in the last year or
> > two on standardizing the representation of world coordinate systems in FITS.
> > Two papers have been published thus far, describing both a general formalism
> > and specific implementation for celestial coordinates.  A third paper is in
> > near-final form, describing spectral coordinate systems.  I was asked to
> > read and comment on this paper, and would like to draw wider attention to it
> > and raise a concern I have to see if it is shared by others in the VO
> > development community.
> >
> > You may find the latest draft of this paper here:
> >
> >     http://www.aoc.nrao.edu/~egreisen/scs_112103.ps.gz
> >     http://www.aoc.nrao.edu/~egreisen/scs_112103.ps
> >
> >
> > My concern is that the paper provides no simple FITS ASCII table
> > representation for spectra in which the wavelength scale is given by an
> > explicit list of values, each with an associated flux.  Rather, it supports
> > a wavelength scale look-up using a FITS BINTABLE extension, and only allows
> > the wavelength and flux arrays to be stored as vectors in single cells.
> > There are advantages to this approach in terms of efficiency and robustness.
> > However, looking ahead to the imminent development of a Simple Spectral
> > Access Protocol, I would expect that a basic encoding scheme for spectra
> > would be a VOTable with columns for wavelength, flux, error, etc.  It seems
> > to me that this VOTable should be as close in structure as a FITS
> > representation as possible, to the point where we should be able to
> > translate the VOTable to FITS with an XML style sheet.  Also, there is much
> > extant software that reads and writes spectra in even simpler ASCII text
> > files, with tab- or space-delimited columns and very simple column headers.
> > Thus, in the interest of the simplest possible interoperability for spectral
> > data, I have suggested to the authors of the FITS spectral WCS paper to
> > consider adding a FITS ASCII table option for the tabular form of a
> > spectrum.  So far I've been told that there is "no way in which it can be
> > implemented."  I do not believe this statement, but would like to hear from
> > others in the VO community before pressing the case further.
> >
> > Thanks,
> > Bob
>
>

From owner-dal@eso.org  Tue Nov 25 19:59:30 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAPIwUYS009595
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 25 Nov 2003 19:58:30 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAPIwUgi009594
	for dal-outgoing; Tue, 25 Nov 2003 19:58:30 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hAPIvrYS009364;
	Tue, 25 Nov 2003 19:57:53 +0100 (MET)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAPIvpB1018127;
	Tue, 25 Nov 2003 19:57:52 +0100 (CET)
Received: from aria (aria.stsci.edu [130.167.236.125])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AHI81769;
	Tue, 25 Nov 2003 13:57:48 -0500 (EST)
Message-ID: <002001c3b386$050a8170$7deca782@stsci.edu>
From: "Robert Hanisch" <hanisch@stsci.edu>
To: "Markus Dolensky" <Markus.Dolensky@eso.org>, <dal@ivoa.net>
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org>
Subject: Re: spectral WCS in FITS
Date: Tue, 25 Nov 2003 13:57:48 -0500
Organization: Space Telescope Science Institute
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu)
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Robert Hanisch" <hanisch@stsci.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


----- Original Message ----- 
From: "Markus Dolensky" <Markus.Dolensky@eso.org>
To: <dal@ivoa.net>
Sent: Tuesday, November 25, 2003 7:11 AM
Subject: Re: spectral WCS in FITS


> It all boils down to the question:
>
> Is there a way to express a vector in a single cell of a FITS ASCII table,
right?
>
> If so, FITS BINTABLE structure proposed by Greisen et al. can be mapped to
> ASCII tables. And consequently XSLT can be used to transform between ASCII
> table and VOTable formats.
>
> I don't know the answer, but at least it should clarify what we are
looking for.
>
> Markus

The answer to "Is there a way to express a vector in a single cell of a FITS
ASCII table?" is no.  In ASCII tables, vectors map into columns.

An earlier draft of the spectral WCS used binary tables, but entire columns
rather than vector cells.  That format would indeed have been representable
in ASCII tables.

To respond to Anita, the spectral WCS proposal is quite intimately tied to
FITS.  The coordinate transformations, of course, can stand alone, but how
the data is structured does depend on the capabilities of FITS.  Which is,
again, the reason for my query to VO folks.  There are FITS representations
which map quite cleanly to VOTable, and there are FITS representations that
do not (and thus get wrapped by a VOTable).  It is fine to say let FITS be
FITS, we don't care, but for the case of simple 1-d spectra and SEDs where
the data structures Could be extremely similar, should we push to have them
so?

Bob

From owner-dal@eso.org  Wed Nov 26 21:39:24 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAQKYPdM026020
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 26 Nov 2003 21:34:25 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAQKYPZA026019
	for dal-outgoing; Wed, 26 Nov 2003 21:34:25 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAQKYNho026002
	for <dal@ivoa.net>; Wed, 26 Nov 2003 21:34:23 +0100 (MET)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hAQKYNt27552
	for <dal@ivoa.net>; Wed, 26 Nov 2003 21:34:23 +0100 (MET)
Message-ID: <3FC50E42.4050000@eso.org>
Date: Wed, 26 Nov 2003 21:34:10 +0100
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Re: spectral WCS in FITS
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org> <002001c3b386$050a8170$7deca782@stsci.edu>
In-Reply-To: <002001c3b386$050a8170$7deca782@stsci.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Robert Hanisch wrote:
> An earlier draft of the spectral WCS used binary tables, but entire columns
> rather than vector cells.  That format would indeed have been representable
> in ASCII tables.

In that case I strongly support the earlier approach with exactly one value per 
table cell. Even more so, IF the reasons to change it was just performance 
related(?).

Anita Richards wrote:
> Put another way, there is certainly the need for a standard, but that
> should be independent of how it is implimented to describe FITS, VOTable,
> ascii or whatever.

In case of a data model it should indeed be independent of a particular 
implementation. But a data access layer without hooks to existing formats and 
protocols appears of little practical use. Therefore, it does make sense to 
keep in sync with the FITS community as far as data representation is 
concerned. If not we pay the price in terms of more complicated systems.

Markus

From owner-dal@eso.org  Thu Nov 27 11:40:41 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARAdcbe001339
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 27 Nov 2003 11:39:38 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hARAdc4m001338
	for dal-outgoing; Thu, 27 Nov 2003 11:39:38 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hARAd5be001207;
	Thu, 27 Nov 2003 11:39:05 +0100 (MET)
Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hARAd4B1010160;
	Thu, 27 Nov 2003 11:39:04 +0100 (CET)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1APJY8-000DLn-7o; Thu, 27 Nov 2003 10:39:04 +0000
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1APJY8-0001tq-00; Thu, 27 Nov 2003 10:39:04 +0000
Date: Thu, 27 Nov 2003 10:39:03 +0000 (GMT)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Markus Dolensky <Markus.Dolensky@eso.org>
cc: dal@ivoa.net
Subject: Re: spectral WCS in FITS
In-Reply-To: <3FC50E42.4050000@eso.org>
Message-ID: <Pine.GSO.4.53.0311271017460.5200@adikia>
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org>
 <002001c3b386$050a8170$7deca782@stsci.edu> <3FC50E42.4050000@eso.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1APJY8-000DLn-7o*nUDmo/YWuSk*
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


>
> Anita Richards wrote:
> > Put another way, there is certainly the need for a standard, but that
> > should be independent of how it is implimented to describe FITS, VOTable,
> > ascii or whatever.
>
> In case of a data model it should indeed be independent of a particular
> implementation. But a data access layer without hooks to existing formats and
> protocols appears of little practical use. Therefore, it does make sense to
> keep in sync with the FITS community as far as data representation is
> concerned. If not we pay the price in terms of more complicated systems.
>

You are quite right - and maybe someone could give examples of actual
teleescope data in formats which could (not) be handled effectively - e.g.
Bob mentioned the large amount of single dish data which are simply ascii
tables of flux density/T_A (possibly at 2 pols, possibly with other
quantities) versus wavelength or equivalent e.g. chann. No (indeed not
necessarily linearly or even regularly related to wavelength).  However
unless I ahve misunderstood the debate, there is no question that the data
_can_ be handled, it is simply a question of how, and surely testing on
real data (or at least a detailed thought experiment) is the way to
proceed?

I agree with Markus that VOTable standards should recognise all standard
FITS but is the reverse necessary? i.e. if VOTable can do more than FITS,
is that a problem? So long as conversion in both directions is possible,
but possibly with loss of information.  What I am thinking of is:

FITS native spectrum > VOTable > FITS  all original information restored
                                       but some added info from VOTable
				       may be lost
VOTable native format > FITS some info may be lost

but in both cases, is the lost information material which FITS handling
tools can't cope with anyway? And if so, can't it be included as a VOTable
wrapper (and also accessible in human readable form so you know aht is not
accessble to your FITS tool but ou might like to know anyway?)

Or have I completely missed the point in whch case don't worry about
replying, I will shut up and listen.


thanks

A

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).


From owner-dal@eso.org  Thu Nov 27 19:28:33 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARIRcbe006421
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 27 Nov 2003 19:27:38 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hARIRcPn006418
	for dal-outgoing; Thu, 27 Nov 2003 19:27:38 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARIRZ3r006407
	for <dal@ivoa.net>; Thu, 27 Nov 2003 19:27:35 +0100 (MET)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hARIRZt21057
	for <dal@ivoa.net>; Thu, 27 Nov 2003 19:27:35 +0100 (MET)
Message-ID: <3FC6420A.9020608@eso.org>
Date: Thu, 27 Nov 2003 19:27:22 +0100
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: dal@ivoa.net
Subject: Re: spectral WCS in FITS
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org> <002001c3b386$050a8170$7deca782@stsci.edu> <3FC50E42.4050000@eso.org> <Pine.GSO.4.53.0311271017460.5200@adikia>
In-Reply-To: <Pine.GSO.4.53.0311271017460.5200@adikia>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> However
> unless I ahve misunderstood the debate, there is no question that the data
> _can_ be handled, it is simply a question of how, 

The question is whether we can perform the conversion between VOTable and FITS 
format using off the shelve tools (XSLT). If not we need to write Astronomy 
specific parsers which 'understand' the data whereas we would prefer to apply 
just syntax rules instead.

Markus


From owner-dal@eso.org  Thu Nov 27 19:40:58 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARIeEbe010764
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 27 Nov 2003 19:40:14 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hARIeESR010763
	for dal-outgoing; Thu, 27 Nov 2003 19:40:14 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hARIdebe010548;
	Thu, 27 Nov 2003 19:39:40 +0100 (MET)
Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hARIdds3023570;
	Thu, 27 Nov 2003 19:39:39 +0100 (CET)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1APR3D-00030G-BN; Thu, 27 Nov 2003 18:39:39 +0000
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1APR3D-0005NA-00; Thu, 27 Nov 2003 18:39:39 +0000
Date: Thu, 27 Nov 2003 18:39:39 +0000 (GMT)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Markus Dolensky <Markus.Dolensky@eso.org>
cc: dal@ivoa.net
Subject: Re: spectral WCS in FITS
In-Reply-To: <3FC6420A.9020608@eso.org>
Message-ID: <Pine.GSO.4.53.0311271835180.5200@adikia>
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org>
 <002001c3b386$050a8170$7deca782@stsci.edu> <3FC50E42.4050000@eso.org>
 <Pine.GSO.4.53.0311271017460.5200@adikia> <3FC6420A.9020608@eso.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1APR3D-00030G-BN*iC7Ua6HTG8.*
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000



On Thu, 27 Nov 2003, Markus Dolensky wrote:

> > However
> > unless I ahve misunderstood the debate, there is no question that the data
> > _can_ be handled, it is simply a question of how,
>
> The question is whether we can perform the conversion between VOTable and FITS
> format using off the shelve tools (XSLT). If not we need to write Astronomy
> specific parsers which 'understand' the data whereas we would prefer to apply
> just syntax rules instead.
>
> Markus
>
>
>

For FITS to VOTable, there is also the tool being developed by VO India
http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm
which is indended to eventually cope with FITS.

But what about the reverse? That is more difficult, surely?

cheers
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).


From owner-dal@eso.org  Thu Nov 27 20:06:26 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARJ5Nbe019362
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 27 Nov 2003 20:05:23 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hARJ5NiW019360
	for dal-outgoing; Thu, 27 Nov 2003 20:05:23 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARJ5G3r019311;
	Thu, 27 Nov 2003 20:05:16 +0100 (MET)
Received: from eso.org (nb008487.ads.eso.org [134.171.27.211])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hARJ5Ft21453;
	Thu, 27 Nov 2003 20:05:15 +0100 (MET)
Message-ID: <3FC64AEB.2090300@eso.org>
Date: Thu, 27 Nov 2003 20:05:15 +0100
From: "Marco C. Leoni" <mleoni@eso.org>
Organization: Astrophysical Virtual Observatory @ESO
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Anita Richards <amsr@jb.man.ac.uk>
CC: dal@ivoa.net, Andreas Wicenec <awicenec@eso.org>
Subject: Re: spectral WCS in FITS
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org> <002001c3b386$050a8170$7deca782@stsci.edu> <3FC50E42.4050000@eso.org> <Pine.GSO.4.53.0311271017460.5200@adikia> <3FC6420A.9020608@eso.org> <Pine.GSO.4.53.0311271835180.5200@adikia>
In-Reply-To: <Pine.GSO.4.53.0311271835180.5200@adikia>
Content-Type: multipart/alternative;
 boundary="------------080908030600080401000108"
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Marco C. Leoni" <mleoni@eso.org>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

This is a multi-part message in MIME format.
--------------080908030600080401000108
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Anita,
    about the conversions FITS<--->VOTable there was the proposal from 
Andreas, please have a look at: http://www.ivoa.net/forum/votable/0217.htm


Cheers,
    Marco


Anita Richards wrote:

>On Thu, 27 Nov 2003, Markus Dolensky wrote:
>
>  
>
>>>However
>>>unless I ahve misunderstood the debate, there is no question that the data
>>>_can_ be handled, it is simply a question of how,
>>>      
>>>
>>The question is whether we can perform the conversion between VOTable and FITS
>>format using off the shelve tools (XSLT). If not we need to write Astronomy
>>specific parsers which 'understand' the data whereas we would prefer to apply
>>just syntax rules instead.
>>
>>Markus
>>
>>
>>
>>    
>>
>
>For FITS to VOTable, there is also the tool being developed by VO India
>http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm
>which is indended to eventually cope with FITS.
>
>But what about the reverse? That is more difficult, surely?
>
>cheers
>a
>
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>Dr. Anita M. S. Richards, AVO Astronomer
>MERLIN/VLBI National Facility, University of Manchester,
>Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
>tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
>  
>

--------------080908030600080401000108
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<big><small><tt>Anita,<br>
&nbsp;&nbsp;&nbsp; about the conversions FITS&lt;---&gt;VOTable there was the proposal
from Andreas, please have a look at<big>: </big><a class="moz-txt-link-freetext" href="http://www.ivoa.net/forum/votable/0217.htm">http://www.ivoa.net/forum/votable/0217.htm</a><br>
<br>
<br>
Cheers,<br>
&nbsp;&nbsp;&nbsp; Marco</tt></small><br>
</big><br>
<br>
Anita Richards wrote:<br>
<blockquote type="cite"
 cite="midPine.GSO.4.53.0311271835180.5200@adikia">
  <pre wrap="">
On Thu, 27 Nov 2003, Markus Dolensky wrote:

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">However
unless I ahve misunderstood the debate, there is no question that the data
_can_ be handled, it is simply a question of how,
      </pre>
    </blockquote>
    <pre wrap="">The question is whether we can perform the conversion between VOTable and FITS
format using off the shelve tools (XSLT). If not we need to write Astronomy
specific parsers which 'understand' the data whereas we would prefer to apply
just syntax rules instead.

Markus



    </pre>
  </blockquote>
  <pre wrap=""><!---->
For FITS to VOTable, there is also the tool being developed by VO India
<a class="moz-txt-link-freetext" href="http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm">http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm</a>
which is indended to eventually cope with FITS.

But what about the reverse? That is more difficult, surely?

cheers
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
  </pre>
</blockquote>
</body>
</html>

--------------080908030600080401000108--

From owner-dal@eso.org  Thu Nov 27 20:15:15 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARJEVbe022378
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 27 Nov 2003 20:14:31 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hARJEV4c022375
	for dal-outgoing; Thu, 27 Nov 2003 20:14:31 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hARJDube022134;
	Thu, 27 Nov 2003 20:13:56 +0100 (MET)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hARJDtB1001554;
	Thu, 27 Nov 2003 20:13:55 +0100 (CET)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1APRaN-0005in-CU; Thu, 27 Nov 2003 19:13:55 +0000
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1APRaN-0005UH-00; Thu, 27 Nov 2003 19:13:55 +0000
Date: Thu, 27 Nov 2003 19:13:55 +0000 (GMT)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: marco.leoni@eso.org
cc: dal@ivoa.net, Andreas Wicenec <awicenec@eso.org>
Subject: Re: spectral WCS in FITS
In-Reply-To: <3FC64AEB.2090300@eso.org>
Message-ID: <Pine.GSO.4.53.0311271910030.5200@adikia>
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org>
 <002001c3b386$050a8170$7deca782@stsci.edu> <3FC50E42.4050000@eso.org>
 <Pine.GSO.4.53.0311271017460.5200@adikia> <3FC6420A.9020608@eso.org>
 <Pine.GSO.4.53.0311271835180.5200@adikia> <3FC64AEB.2090300@eso.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1APRaN-0005in-CU*xGq5t7IMIOY*
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000



Yes but "The binary data is still kept as external links in a STREAM
element"

If that is what we are talking about then there is no problem... what I
*thought* was the problem included the possibility of converting spectral
data in the form of FITS tables entirely to VOTable (probably OK?) and
back again.  But if no-one wants to do that, that is fine...

a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).


On Thu, 27 Nov 2003, Marco C. Leoni wrote:

> Anita,
>     about the conversions FITS<--->VOTable there was the proposal from
> Andreas, please have a look at: http://www.ivoa.net/forum/votable/0217.htm
>
>
> Cheers,
>     Marco
>
>
> Anita Richards wrote:
>
> >On Thu, 27 Nov 2003, Markus Dolensky wrote:
> >
> >
> >
> >>>However
> >>>unless I ahve misunderstood the debate, there is no question that the data
> >>>_can_ be handled, it is simply a question of how,
> >>>
> >>>
> >>The question is whether we can perform the conversion between VOTable and FITS
> >>format using off the shelve tools (XSLT). If not we need to write Astronomy
> >>specific parsers which 'understand' the data whereas we would prefer to apply
> >>just syntax rules instead.
> >>
> >>Markus
> >>
> >>
> >>
> >>
> >>
> >
> >For FITS to VOTable, there is also the tool being developed by VO India
> >http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm
> >which is indended to eventually cope with FITS.
> >
> >But what about the reverse? That is more difficult, surely?
> >
> >cheers
> >a
> >
> >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >Dr. Anita M. S. Richards, AVO Astronomer
> >MERLIN/VLBI National Facility, University of Manchester,
> >Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> >tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
> >
> >
>

From owner-dal@eso.org  Thu Nov 27 20:22:39 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hARJLlbe025480
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 27 Nov 2003 20:21:47 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hARJLl4Q025478
	for dal-outgoing; Thu, 27 Nov 2003 20:21:47 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hARJLBbe025118;
	Thu, 27 Nov 2003 20:21:11 +0100 (MET)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hARJLAB1002053;
	Thu, 27 Nov 2003 20:21:10 +0100 (CET)
Received: from axp0.ast.man.ac.uk ([130.88.9.45])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1APRhO-0007GP-AJ; Thu, 27 Nov 2003 19:21:10 +0000
Received: from dsb (helo=localhost)
	by axp0.ast.man.ac.uk with local-esmtp (Exim 2.12 #1)
	id 1APRhN-0004Qh-00; Thu, 27 Nov 2003 19:21:09 +0000
Date: Thu, 27 Nov 2003 19:21:09 +0000 (GMT)
From: David Berry <dsb@ast.man.ac.uk>
To: Markus Dolensky <Markus.Dolensky@eso.org>
cc: dal@ivoa.net
Subject: Re: spectral WCS in FITS
In-Reply-To: <3FC6420A.9020608@eso.org>
Message-ID: <Pine.OSF.4.53.0311271911460.30716@axp0.ast.man.ac.uk>
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC3470D.2070103@eso.org>
 <002001c3b386$050a8170$7deca782@stsci.edu> <3FC50E42.4050000@eso.org>
 <Pine.GSO.4.53.0311271017460.5200@adikia> <3FC6420A.9020608@eso.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1APRhO-0007GP-AJ*gdLOb3TGwnE*
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: David Berry <dsb@ast.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


> The question is whether we can perform the conversion between VOTable and FITS
> format using off the shelve tools (XSLT). If not we need to write Astronomy
> specific parsers which 'understand' the data whereas we would prefer to apply
> just syntax rules instead.

It will no doubt be possible to use XSLT in many cases. But to say that
it must *always* be possible to transform VOTABLE into FITS (without
loss), using XSLT seems to take away the point of having VOTABLE. If
VOTABLE is not allowed to be anything other than a direct equivalent of
a FITS file, why not just use FITS?

David


----------------------------------------------------------------------
Dr David S. Berry    (dsb@ast.man.ac.uk)

STARLINK project		 |	Centre for Astrophysics
(http://www.starlink.ac.uk/)	 |	University of Central Lancashire
Rutherford Appleton Laboratory	 |	PRESTON
DIDCOT				 |	United Kingdom
United Kingdom			 |	PR1 2HE
OX11 0QX

From owner-dal@eso.org  Fri Nov 28 09:51:42 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAS8oMjQ028041
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 28 Nov 2003 09:50:22 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAS8oLxf028039
	for dal-outgoing; Fri, 28 Nov 2003 09:50:21 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAS8oDUn027990;
	Fri, 28 Nov 2003 09:50:13 +0100 (MET)
Received: from arclux2.hq.eso.org (pc003189.hq.eso.org [134.171.3.55])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hAS8oCt01549;
	Fri, 28 Nov 2003 09:50:12 +0100 (MET)
From: Andreas Wicenec <awicenec@eso.org>
Organization: European Southern Observatory
To: Anita Richards <amsr@jb.man.ac.uk>, marco.leoni@eso.org
Subject: Re: spectral WCS in FITS
Date: Fri, 28 Nov 2003 09:50:12 +0100
User-Agent: KMail/1.5.1
Cc: dal@ivoa.net
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC64AEB.2090300@eso.org> <Pine.GSO.4.53.0311271910030.5200@adikia>
In-Reply-To: <Pine.GSO.4.53.0311271910030.5200@adikia>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200311280950.12116.awicenec@eso.org>
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Andreas Wicenec <awicenec@eso.org>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Anita,

I think we should start with the following concept:

- Convert FITS binary tables to VOTable with <STREAM> elements or binary 
attachments, i.e. don't touch the binary part, but just describe it.

- Convert FITS ASCII tables to fully tagged VOTables with <TABLEDATA> 
elements.

The reverse conversions should then also be possible (see my example).
The cross conversion between the two is more tricky and requires that the 
converter needs to know how to deal with the binary part. This is also 
possible, but not with plain XSLT although it can be done by using external 
functions called by the xslt processor. I did bot try it yet, but I guess it 
is not really complicated for simple binary tables. The problem starts when 
you want to deal with complicated radio or other interferometric data which 
are represented using hierarchical table structures with many multiplicity 
levels (baselines, basebands, polarisations, frequency channles). VOTable is 
not yet able to fully deal with this kind of data and the way it is 
implemented in FITS is also not really self-describing, i.e. there is a lot 
of implicit knowledge necessary to interpret the complete data structure of 
something like an AIPS++ measurement set. On the other hand the amount of 
data and the complexity of such structures makes pure ASCII representations 
pretty bulky and nobody really gains from being able to read it or load it 
into an editor, because it is almost impossible to do anything reasonable 
interactively anyway.

Another comment to your and Doug's e-mails yesterday:
We made quite some progress with the ALMA data model during our meeting in 
Santa Fe last week (Doug was present as well). There will be another round in 
January with less people to bring this to a level where we can actually draft 
a document on it. After this I think we should also open this up for 
discussion on radiovo@ivoa.net.

Cheers,
Andreas

On Thursday 27 November 2003 20:13, Anita Richards wrote:
> Yes but "The binary data is still kept as external links in a STREAM
> element"
>
> If that is what we are talking about then there is no problem... what I
> *thought* was the problem included the possibility of converting spectral
> data in the form of FITS tables entirely to VOTable (probably OK?) and
> back again.  But if no-one wants to do that, that is fine...
>
> a
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Dr. Anita M. S. Richards, AVO Astronomer
> MERLIN/VLBI National Facility, University of Manchester,
> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
>
> On Thu, 27 Nov 2003, Marco C. Leoni wrote:
> > Anita,
> >     about the conversions FITS<--->VOTable there was the proposal from
> > Andreas, please have a look at:
> > http://www.ivoa.net/forum/votable/0217.htm
> >
> >
> > Cheers,
> >     Marco
> >
> > Anita Richards wrote:
> > >On Thu, 27 Nov 2003, Markus Dolensky wrote:
> > >>>However
> > >>>unless I ahve misunderstood the debate, there is no question that the
> > >>> data _can_ be handled, it is simply a question of how,
> > >>
> > >>The question is whether we can perform the conversion between VOTable
> > >> and FITS format using off the shelve tools (XSLT). If not we need to
> > >> write Astronomy specific parsers which 'understand' the data whereas
> > >> we would prefer to apply just syntax rules instead.
> > >>
> > >>Markus
> > >
> > >For FITS to VOTable, there is also the tool being developed by VO India
> > >http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm
> > >which is indended to eventually cope with FITS.
> > >
> > >But what about the reverse? That is more difficult, surely?
> > >
> > >cheers
> > >a
> > >
> > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > >Dr. Anita M. S. Richards, AVO Astronomer
> > >MERLIN/VLBI National Facility, University of Manchester,
> > >Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> > >tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).

From owner-dal@eso.org  Fri Nov 28 10:56:24 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hAS9tTjQ016885
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 28 Nov 2003 10:55:29 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hAS9tTwW016884
	for dal-outgoing; Fri, 28 Nov 2003 10:55:29 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hAS9stjQ016741;
	Fri, 28 Nov 2003 10:54:55 +0100 (MET)
Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hAS9stB1025638;
	Fri, 28 Nov 2003 10:54:55 +0100 (CET)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1APfKw-0000Iw-QQ; Fri, 28 Nov 2003 09:54:54 +0000
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1APfKw-0005uT-00; Fri, 28 Nov 2003 09:54:54 +0000
Date: Fri, 28 Nov 2003 09:54:54 +0000 (GMT)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Andreas Wicenec <awicenec@eso.org>
cc: marco.leoni@eso.org, dal@ivoa.net
Subject: Re: spectral WCS in FITS
In-Reply-To: <200311280950.12116.awicenec@eso.org>
Message-ID: <Pine.GSO.4.53.0311280947290.5200@adikia>
References: <004501c3b130$eccb5140$b4324d0c@euttq> <3FC64AEB.2090300@eso.org>
 <Pine.GSO.4.53.0311271910030.5200@adikia> <200311280950.12116.awicenec@eso.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1APfKw-0000Iw-QQ*TNRLWMLyXlc*
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> From: Andreas Wicenec <awicenec@eso.org>
>
> I think we should start with the following concept:
>
1.
> - Convert FITS binary tables to VOTable with <STREAM> elements or binary
> attachments, i.e. don't touch the binary part, but just describe it.
>
2.
> - Convert FITS ASCII tables to fully tagged VOTables with <TABLEDATA>
> elements.

Thanks Andreas, that is what I hoped was the case.  As you say below,
there is no point in converting anything more complex entirely to VOTable,
as complex FITS binary data are unusable (or vastly less accessible at
best) in that form any way.

However, to go back to Bob's original question, is there anything in (or
missing from) the WCS Spectral Coordinates document which makes (2.) (or
its reverse) difficult? If not, then I agree with Dave Berry's comment
that we should not force VOTable and FITS to be identical.


best wishes

Anita

>
> The reverse conversions should then also be possible (see my example).
> The cross conversion between the two is more tricky and requires that the
> converter needs to know how to deal with the binary part. This is also
> possible, but not with plain XSLT although it can be done by using external
> functions called by the xslt processor. I did bot try it yet, but I guess it
> is not really complicated for simple binary tables. The problem starts when
> you want to deal with complicated radio or other interferometric data which
> are represented using hierarchical table structures with many multiplicity
> levels (baselines, basebands, polarisations, frequency channles). VOTable is
> not yet able to fully deal with this kind of data and the way it is
> implemented in FITS is also not really self-describing, i.e. there is a lot
> of implicit knowledge necessary to interpret the complete data structure of
> something like an AIPS++ measurement set. On the other hand the amount of
> data and the complexity of such structures makes pure ASCII representations
> pretty bulky and nobody really gains from being able to read it or load it
> into an editor, because it is almost impossible to do anything reasonable
> interactively anyway.
>
> Cheers,
> Andreas
>
> On Thursday 27 November 2003 20:13, Anita Richards wrote:
> > Yes but "The binary data is still kept as external links in a STREAM
> > element"
> >
> > If that is what we are talking about then there is no problem... what I
> > *thought* was the problem included the possibility of converting spectral
> > data in the form of FITS tables entirely to VOTable (probably OK?) and
> > back again.  But if no-one wants to do that, that is fine...
> >
> > a
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > Dr. Anita M. S. Richards, AVO Astronomer
> > MERLIN/VLBI National Facility, University of Manchester,
> > Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> > tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
> >
> > On Thu, 27 Nov 2003, Marco C. Leoni wrote:
> > > Anita,
> > >     about the conversions FITS<--->VOTable there was the proposal from
> > > Andreas, please have a look at:
> > > http://www.ivoa.net/forum/votable/0217.htm
> > >
> > >
> > > Cheers,
> > >     Marco
> > >
> > > Anita Richards wrote:
> > > >On Thu, 27 Nov 2003, Markus Dolensky wrote:
> > > >>>However
> > > >>>unless I ahve misunderstood the debate, there is no question that the
> > > >>> data _can_ be handled, it is simply a question of how,
> > > >>
> > > >>The question is whether we can perform the conversion between VOTable
> > > >> and FITS format using off the shelve tools (XSLT). If not we need to
> > > >> write Astronomy specific parsers which 'understand' the data whereas
> > > >> we would prefer to apply just syntax rules instead.
> > > >>
> > > >>Markus
> > > >
> > > >For FITS to VOTable, there is also the tool being developed by VO India
> > > >http://vo.iucaa.ernet.in/~voi/votableStreamWriter.htm
> > > >which is indended to eventually cope with FITS.
> > > >
> > > >But what about the reverse? That is more difficult, surely?
> > > >
> > > >cheers
> > > >a
> > > >
> > > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > >Dr. Anita M. S. Richards, AVO Astronomer
> > > >MERLIN/VLBI National Facility, University of Manchester,
> > > >Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> > > >tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
>
>

From owner-dal@eso.org  Wed Dec  3 07:32:16 2003
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hB36VIwe026085
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 3 Dec 2003 07:31:18 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB36VIfg026084
	for dal-outgoing; Wed, 3 Dec 2003 07:31:18 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id hB36Uiwe026023
	for <dal@ivoa.net>; Wed, 3 Dec 2003 07:30:44 +0100 (MET)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id hB36Uhd8004843
	for <dal@ivoa.net>; Wed, 3 Dec 2003 07:30:44 +0100 (CET)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id hB36UeqC001219;
	Tue, 2 Dec 2003 23:30:40 -0700
Date: Tue, 2 Dec 2003 23:30:36 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Robert Hanisch <hanisch@stsci.edu>
cc: dal@ivoa.net
Subject: Re: spectral WCS in FITS
In-Reply-To: <004501c3b130$eccb5140$b4324d0c@euttq>
Message-ID: <Pine.LNX.4.44.0312022257160.11419-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi All -

Bob writes:
> My concern is that the paper provides no simple FITS ASCII table
> representation for spectra in which the wavelength scale is given by an
> explicit list of values, each with an associated flux.  Rather, it supports
> a wavelength scale look-up using a FITS BINTABLE extension, and only allows
> the wavelength and flux arrays to be stored as vectors in single cells.

I have only just started to look at this issue, and may have better
informed opinions later , but I have a few initial comments.

First, BINTABLE is is a major part of FITS, used for much current
astronomical data.  We should not be trying to force FITS to abandon
BINTABLE for an inferior solution just because BINTABLE is inconvenient
to use with XSLT.

Having just read the latest draft WCS paper III it is clear that there
are good reasons for the use of BINTABLE for the sampled spectral WCS
coordinate vector.  The main reason for this is to allow a spectral
WCS to map cleanly onto a spectral data format which stores multiple
spectra as the rows of a binary table (a widely used technique which is
probably the best approach available for multi-object spectrographs).
This allows the use of a sampled WCS without having to use a separate
FITS extension.  If an ASCII table were the only option, it would be
necessary to use a separate ASCII table extension for every spectrum in a
multi-spectrum BINTABLE that might contain thousands of spectra.  Hence,
it is necessary for FITS spectral WCS to support BINTABLE for storing a
sampled WCS coordinate vector.  It is necessary to store the vector in
a single table cell to allow a direct mapping onto a spectrum stored as
a table row.  If only a single format option is provided, this would be
the best one to pick.

If we were to store a single spectrum in a single ASCII (or binary)
table, storing the vectors in columns of the table, then it would be
straightforward to have a column (rather than cell) for the sampled
WCS coordinate vector.  I see no reason this could not be allowed by
spectral WCS for single-spectrum-per-table spectral formats.  The cost
would be to provide two alternate options for representing a sampled
WCS coordinate vector.  The storage representation would differ from the
current spectral WCS spec, but the WCS data model is the same in both cases
(with the minor restriction that the index vector would not be permitted
for a same-table mapping, but it is not needed anyway for this format).

On the other hand we could also easily support the use of BINTABLE for
FITS spectra which map to VOTable.  If a table has only one row, there is
no significant difference between a vector valued table cell with N values
and a column with N rows.  Logically there is essentially no difference.
Since BINTABLE is already a binary format it really does not matter.
If we wanted to do text-based translation we could post-process the
text with a BINTABLE formatter component without loss of flexibility.
The real question is do we want to define multiple FITS spectral data
representations, e.g., for both ASCII tables and BINTABLE.

More on this later as we think more about spectral data formats for SSA.

	- Doug


From owner-avo-sci@eso.org  Thu Dec  4 20:04:47 2003
Return-Path: <owner-avo-sci@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hB4J4WlK023535
	for <avo-sci-outgoing@mercury.hq.eso.org>; Thu, 4 Dec 2003 20:04:32 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id hB4J4WPe023534
	for avo-sci-outgoing; Thu, 4 Dec 2003 20:04:32 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-avo-sci@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id hB4J2E1u022783;
	Thu, 4 Dec 2003 20:02:14 +0100 (MET)
Received: from eso.org (nb008487.ads.eso.org [134.171.27.211])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id hB4J2Et07715;
	Thu, 4 Dec 2003 20:02:14 +0100 (MET)
Message-ID: <3FCF84B6.9070507@eso.org>
Date: Thu, 04 Dec 2003 20:02:14 +0100
From: "Marco C. Leoni" <mleoni@eso.org>
Organization: Astrophysical Virtual Observatory @ESO
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: mleoni@eso.org
Subject: Server down
X-Priority: 1 (highest)
Content-Type: multipart/alternative;
 boundary="------------000202050900060205000601"
Sender: owner-avo-sci@eso.org
Precedence: bulk
Reply-To: "Marco C. Leoni" <mleoni@eso.org>
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Mozilla-Status: c001
X-Mozilla-Status2: 00000000

This is a multi-part message in MIME format.
--------------000202050900060205000601
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Due to maintenance of the electrical systems this week-end in Garching, 
we have been requested to switch off all computer systems during this 
period.
For this reason all the services (mailing lists, web sites, twikis) will 
be unavailable on Saturday Dec. 6 .

Sorry for the short notice.


Best regards,
    Marco




-- 
Marco C. Leoni

Astrophysical Virtual Observatory - http://www.euro-vo.org
tel 	0049 89 3200 6560
fax 	0049 89 3200 6480

mleoni@eso.org

--------------000202050900060205000601
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<big>Due to maintenance of the electrical systems this week-end in
Garching, we have been requested to switch off all computer systems
during this period.<br>
For this reason all the services (mailing lists, web sites, twikis)
will be unavailable on Saturday Dec. 6 .<br>
<br>
Sorry for the short notice.<br>
<br>
<br>
Best regards,<br>
&nbsp;&nbsp;&nbsp; Marco</big><br>
<br>
<br>
<br>
<br>
<div class="moz-signature">-- <br>
<b><font color="#000066" face="Arial,cursive">Marco C. Leoni</font></b><br>
<br>
<font color="#000066">
<i><b>A</b>strophysical <b>V</b>irtual <b>O</b>bservatory</i> -
<a class="moz-txt-link-freetext" href="http://www.euro-vo.org">http://www.euro-vo.org</a><br>
<table border="0">
  <tbody>
    <tr>
      <td>tel</td>
      <td>0049 89 3200 6560</td>
    </tr>
    <tr>
      <td>fax</td>
      <td>0049 89 3200 6480</td>
    </tr>
  </tbody>
</table>
<a class="moz-txt-link-abbreviated" href="mailto:mleoni@eso.org">mleoni@eso.org</a>
</font></div>
</body>
</html>

--------------000202050900060205000601--

From owner-dal@eso.org  Tue Feb  3 20:11:15 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i13JAuDk017737
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 3 Feb 2004 20:10:56 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i13JAuBH017736
	for dal-outgoing; Tue, 3 Feb 2004 20:10:56 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with SMTP id i13JArDk017712;
	Tue, 3 Feb 2004 20:10:54 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with SMTP id i13JAoWR010227;
	Tue, 3 Feb 2004 20:10:51 +0100 (CET)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i13JAiE01649;
	Tue, 3 Feb 2004 12:10:44 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i13JAgxq020790;
	Tue, 3 Feb 2004 12:10:43 -0700 (MST)
Date: Tue, 3 Feb 2004 12:10:42 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: martin hill <mchill@dial.pipex.com>
cc: dm@ivoa.net, <dal@ivoa.net>
Subject: Re: Representing data
In-Reply-To: <1075809357.401f8c4ddc040@netmail.pipex.net>
Message-ID: <Pine.LNX.4.44.0402031139550.17728-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.8, required 7,
	BAYES_01 -5.40, IN_REP_TO -0.37, USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

>From Martin:
> So during the meanwhilst - can anyone suggest an email list for discussing
> 'data representations'?  This should include my favourite bee-in-the-bonnet
> topic, inter-service message formats.  Should we start a new one, or perhaps
> use interop@ivoa.net?

I suggest using dal@ivoa.net for such discussions.  Within the NVO at
least, data representation is considered part of data access, since a
DAL service has to return data in some form.  The major elements of a
DAL service are the query and the data access method, which returns some
virtual (computed on demand) data object conformant to the VO data models.

Ideally we define data models in the abstract, perhaps including a
verification schema (this is the task of the DM working group), and can
represent data in various ways, e.g., VOTable or some other XML format,
FITS, or a combination of XML (for metadata) and FITS (for binary data).
The data model should be the same regardless of the data representation,
allowing software to be written for a particular data object or component
data model to be usable regardless of the access protocol and data
representation used.  We may use slightly different representations for
small datasets and for bulk data.

We have an immediate need to do this for spectral and time series data for
the SSA interface.  We can use SSA as a test case to experiment with new
approaches to data representation, e.g., by extending VOTable to allow
datasets to be composed from data model components, each with their own
namespace and schema, combined with storage elements such as table.

	- Doug

From owner-dal@eso.org  Wed Mar 24 19:46:00 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OIjQvR008187
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 24 Mar 2004 19:45:26 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2OIjQkm008186
	for dal-outgoing; Wed, 24 Mar 2004 19:45:26 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OIjNvR008174;
	Wed, 24 Mar 2004 19:45:23 +0100 (MET)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2OIjK3R007309;
	Wed, 24 Mar 2004 19:45:21 +0100 (CET)
Received: from SARA (roy-nat.cacr.caltech.edu [131.215.144.149])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2OIjIk4002303
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Wed, 24 Mar 2004 10:45:19 -0800
Message-ID: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: <dal@ivoa.net>, <ucd@ivoa.net>
Subject: New UCD1+ for SIA protocol
Date: Wed, 24 Mar 2004 10:45:35 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear UCD and DAL folks

Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been
working on an update for the SIA protocol that uses the standard UCD set,
now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been
using.

In the following, all UCD from the original SIA specification are listed
below. The old SIA UCD is written first, then the suggested new UCD1+ is
written in the line beginning "-->"

The UCD1+ is not fully documented yet, but you can find a dictionary from
UCD1 to UCD1+ at
http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt
and
http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt

The SIA protocol is defined at
http://us-vo.org/pubs/files/ACF8DE.pdf

The new SIA will be version 1.1, and we are hoping to draft and approve this
at the IVOA meeting at the end of May.

Thank you for your comments and suggestions on these new assignments
Andrea, Roy, Sebastian

--------------------------------------------------------

VOX:Image_Title
--> meta.title
containing a short (usually one line) description of the image. This should
concisely describe the image to a user, typically identifying the image
source (e.g., survey name), object name or field coordinates,
bandpass/filter, and so forth.

INST_ID
--> meta.id;instr
identifying the instrument or instruments used to make the observation,

VOX:Image_MJDateObs
--> time.epoch
representing the mean modified Julian date of the observation.

POS_EQ_RA_MAIN
--> pos.eq.ra
representing the ICRS right-ascension of the center of the image.

POS_EQ_DEC_MAIN
--> pos.eq.dec
representing the ICRS declination of the center of the image.

VOX:Image_Naxes
--> pos.wcs.naxes
specifying the number of image axes.

VOX:Image_Naxis
--> pos.wcs.naxis
with the array value giving the length in pixels of each image axis.

VOX:Image_Scale
--> instr.scale
with the array value giving the scale in degrees per pixel of each image
axis.

VOX:Image_Format
--> meta.code.mime
specifying the MIME-type of the object associated with the image acref,

VOX:STC_CoordRefFrame
--> pos.frame
representing the coordinate system reference frame, selected from "ICRS",
"FK5", "FK4", "ECL", "GAL", and "SGAL".

VOX:STC_CoordEquinox
--> time.equinox
representing the Equinox (not required for ICRS) of the coordinate system

VOX:WCS_CoordProjection
--> pos.wcs.ctype
the array value being the three-character code ("TAN", "ARC", "SIN", and so
forth) specifying the celestial projection

VOX:WCS_CoordRefPixel
--> pos.wcs.crpix
with the array value specifying the image pixel coordinates of the WCS
reference pixel. This is identical to "CRPIX" in FITS WCS.

VOX:WCS_CoordRefValue
--> pos.wcs.crval
with the array value specifying the world coordinates of the WCS reference
pixel. This is identical to "CRVAL" in FITS WCS.

VOX:WCS_CDMatrix
--> pos.wcs.cdmatrix
with the array (matrix) value specifying the WCS CD matrix. This is
identical to the "CD" term in FITS WCS, and defines the scale and rotation
(among other things) of the image.

VOX:BandPass_ID
--> instr.bandpass
identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.).

VOX:BandPass_Unit
--> meta.unit
identifying the units used to represent spectral values, selected from
"meters", "hertz", and "keV".

VOX:BandPass_RefValue
--> em.wl OR em.freq OR em.energy
specifying the characteristic (reference) frequency, wavelength, or energy
for the bandpass model.

VOX:BandPass_HiLimit
--> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max
specifying the upper limit of the bandpass.

VOX:BandPass_LoLimit
--> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min
specifying the lower limit of the bandpass.

VOX:Image_PixFlags
 --> meta.code
specifying the type of processing done by the image service to produce an
output image pixel.

VOX:Image_AccessReference
--> meta.ref.url
specifying the URL to be used to access or retrieve the image.

VOX:Image_AccessRefTTL
--> time.interval;stat.min
specifying the minimum time to live in seconds of the access reference.

VOX:Image_FileSize
--> phys.size;meta.file
representing the actual or estimated size of the encoded image in bytes (not
pixels!).

From owner-dal@eso.org  Wed Mar 24 19:57:18 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OIv2vR010355
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 24 Mar 2004 19:57:02 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2OIv2rA010345
	for dal-outgoing; Wed, 24 Mar 2004 19:57:02 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OIuwvR010324;
	Wed, 24 Mar 2004 19:56:58 +0100 (MET)
Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2OIuumW021979;
	Wed, 24 Mar 2004 19:56:56 +0100 (CET)
Received: (from womullan@localhost)
	by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i2OIutT29883;
	Wed, 24 Mar 2004 13:56:55 -0500
Date: Wed, 24 Mar 2004 13:56:55 -0500
From: "Wil O'Mullane" <womullan@skysrv.pha.jhu.edu>
To: Roy Williams <roy@cacr.caltech.edu>
Cc: dal@ivoa.net, ucd@ivoa.net
Subject: Re: New UCD1+ for SIA protocol
Message-ID: <20040324135655.D29227@skysrv.pha.jhu.edu>
References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>; from roy@cacr.caltech.edu on Wed, Mar 24, 2004 at 10:45:35AM -0800
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Wil O'Mullane" <womullan@skysrv.pha.jhu.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

At the risk of being told this laready and having forgotten ...

why do the standard ones like
POS_EQ_RA_MAIN
change ?

I thought this was a move to reomve the VOX: not
rename all ucds ...

Although I like the dots more than the _..

wil


this will break lots of apps which rely on thoose ucds ..
On Wed, Mar 24, 2004 at 10:45:35AM -0800, Roy Williams wrote:
> Dear UCD and DAL folks
> 
> Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been
> working on an update for the SIA protocol that uses the standard UCD set,
> now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been
> using.
> 
> In the following, all UCD from the original SIA specification are listed
> below. The old SIA UCD is written first, then the suggested new UCD1+ is
> written in the line beginning "-->"
> 
> The UCD1+ is not fully documented yet, but you can find a dictionary from
> UCD1 to UCD1+ at
> http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt
> and
> http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt
> 
> The SIA protocol is defined at
> http://us-vo.org/pubs/files/ACF8DE.pdf
> 
> The new SIA will be version 1.1, and we are hoping to draft and approve this
> at the IVOA meeting at the end of May.
> 
> Thank you for your comments and suggestions on these new assignments
> Andrea, Roy, Sebastian
> 
> --------------------------------------------------------
> 
> VOX:Image_Title
> --> meta.title
> containing a short (usually one line) description of the image. This should
> concisely describe the image to a user, typically identifying the image
> source (e.g., survey name), object name or field coordinates,
> bandpass/filter, and so forth.
> 
> INST_ID
> --> meta.id;instr
> identifying the instrument or instruments used to make the observation,
> 
> VOX:Image_MJDateObs
> --> time.epoch
> representing the mean modified Julian date of the observation.
> 
> POS_EQ_RA_MAIN
> --> pos.eq.ra
> representing the ICRS right-ascension of the center of the image.
> 
> POS_EQ_DEC_MAIN
> --> pos.eq.dec
> representing the ICRS declination of the center of the image.
> 
> VOX:Image_Naxes
> --> pos.wcs.naxes
> specifying the number of image axes.
> 
> VOX:Image_Naxis
> --> pos.wcs.naxis
> with the array value giving the length in pixels of each image axis.
> 
> VOX:Image_Scale
> --> instr.scale
> with the array value giving the scale in degrees per pixel of each image
> axis.
> 
> VOX:Image_Format
> --> meta.code.mime
> specifying the MIME-type of the object associated with the image acref,
> 
> VOX:STC_CoordRefFrame
> --> pos.frame
> representing the coordinate system reference frame, selected from "ICRS",
> "FK5", "FK4", "ECL", "GAL", and "SGAL".
> 
> VOX:STC_CoordEquinox
> --> time.equinox
> representing the Equinox (not required for ICRS) of the coordinate system
> 
> VOX:WCS_CoordProjection
> --> pos.wcs.ctype
> the array value being the three-character code ("TAN", "ARC", "SIN", and so
> forth) specifying the celestial projection
> 
> VOX:WCS_CoordRefPixel
> --> pos.wcs.crpix
> with the array value specifying the image pixel coordinates of the WCS
> reference pixel. This is identical to "CRPIX" in FITS WCS.
> 
> VOX:WCS_CoordRefValue
> --> pos.wcs.crval
> with the array value specifying the world coordinates of the WCS reference
> pixel. This is identical to "CRVAL" in FITS WCS.
> 
> VOX:WCS_CDMatrix
> --> pos.wcs.cdmatrix
> with the array (matrix) value specifying the WCS CD matrix. This is
> identical to the "CD" term in FITS WCS, and defines the scale and rotation
> (among other things) of the image.
> 
> VOX:BandPass_ID
> --> instr.bandpass
> identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.).
> 
> VOX:BandPass_Unit
> --> meta.unit
> identifying the units used to represent spectral values, selected from
> "meters", "hertz", and "keV".
> 
> VOX:BandPass_RefValue
> --> em.wl OR em.freq OR em.energy
> specifying the characteristic (reference) frequency, wavelength, or energy
> for the bandpass model.
> 
> VOX:BandPass_HiLimit
> --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max
> specifying the upper limit of the bandpass.
> 
> VOX:BandPass_LoLimit
> --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min
> specifying the lower limit of the bandpass.
> 
> VOX:Image_PixFlags
>  --> meta.code
> specifying the type of processing done by the image service to produce an
> output image pixel.
> 
> VOX:Image_AccessReference
> --> meta.ref.url
> specifying the URL to be used to access or retrieve the image.
> 
> VOX:Image_AccessRefTTL
> --> time.interval;stat.min
> specifying the minimum time to live in seconds of the access reference.
> 
> VOX:Image_FileSize
> --> phys.size;meta.file
> representing the actual or estimated size of the encoded image in bytes (not
> pixels!).

From owner-ucd@eso.org  Wed Mar 24 20:46:37 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OJkMvR001398
	for <ucd-outgoing@mercury.hq.eso.org>; Wed, 24 Mar 2004 20:46:22 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2OJkMPB001396
	for ucd-outgoing; Wed, 24 Mar 2004 20:46:22 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OJkJvR001370;
	Wed, 24 Mar 2004 20:46:19 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2OJkGmW023737;
	Wed, 24 Mar 2004 20:46:17 +0100 (CET)
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head.cfa.harvard.edu (d/w) with ESMTP id i2OJkEsw005782;
	Wed, 24 Mar 2004 14:46:14 -0500 (EST)
From: Arnold Rots <arots@head.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id i2OJkEu1003422;
	Wed, 24 Mar 2004 14:46:14 -0500 (EST)
Message-Id: <200403241946.i2OJkEu1003422@xebec.cfa.harvard.edu>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>
To: Roy Williams <roy@cacr.caltech.edu>
Date: Wed, 24 Mar 2004 14:46:14 -0500 (EST)
CC: dal@ivoa.net, ucd@ivoa.net
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Arnold Rots <arots@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

SIAP 1.1:

I had asked that SCORE (used to be GRADE) be included in the list of
optional input and output parameters and there seemed to be agreement
that it is a useful thing.

Output
SCORE is a floating point value that ranks returned images according
to their relevance for the query as perceived by the server.  This is
meant to aid the client (especially the non-specialist client) in
choosing from a list of images in case more than one image satisfies
the query criteria.  The scale is always relative and only
meaningful in the context of the result in which it is provided.  It
may measure things like exposure time, image quality, proximity to the
specified position, resolution, etc.

Input
SCORE is a string and may assume two values:
SCORE=TOP
If multiple images satisfy the query criteria, only the one with the
highest value of SCORE (in output) is returned.
SCORE=ALL
(default) All images satisfying the query criteria are returned.


This issue is important for archives of pointed observations where
dozens of images may be available satisfying a single query.  Expert
users may want to see the metadata on all of them and choose, but
less sophisticated users and more general services (the issue came up
in some of our prototypes/demos as a real problem!) are more likely
get annoyed and say: just get me what you think is the best one.  And
that's what this is about.

There is no UCD that fits this, it's a context-dependent thing and,
besides, it has a different datatype on input and output.
But I'd appreciate its being added.

  - Arnold

Roy Williams wrote:
> Dear UCD and DAL folks
> 
> Three of us (Sebastian Derriere, Andrea Preite-Martinez, myself) have been
> working on an update for the SIA protocol that uses the standard UCD set,
> now called UCD1+, rather than the ad hoc namespace VOX that SIA 1.0 has been
> using.
> 
> In the following, all UCD from the original SIA specification are listed
> below. The old SIA UCD is written first, then the suggested new UCD1+ is
> written in the line beginning "-->"
> 
> The UCD1+ is not fully documented yet, but you can find a dictionary from
> UCD1 to UCD1+ at
> http://vizier.u-strasbg.fr/UCD/lists/ucd1-ucd1p.txt
> and
> http://vizier.u-strasbg.fr/UCD/lists/ucd1p-composed.txt
> 
> The SIA protocol is defined at
> http://us-vo.org/pubs/files/ACF8DE.pdf
> 
> The new SIA will be version 1.1, and we are hoping to draft and approve this
> at the IVOA meeting at the end of May.
> 
> Thank you for your comments and suggestions on these new assignments
> Andrea, Roy, Sebastian
> 
> --------------------------------------------------------
> 
> VOX:Image_Title
> --> meta.title
> containing a short (usually one line) description of the image. This should
> concisely describe the image to a user, typically identifying the image
> source (e.g., survey name), object name or field coordinates,
> bandpass/filter, and so forth.
> 
> INST_ID
> --> meta.id;instr
> identifying the instrument or instruments used to make the observation,
> 
> VOX:Image_MJDateObs
> --> time.epoch
> representing the mean modified Julian date of the observation.
> 
> POS_EQ_RA_MAIN
> --> pos.eq.ra
> representing the ICRS right-ascension of the center of the image.
> 
> POS_EQ_DEC_MAIN
> --> pos.eq.dec
> representing the ICRS declination of the center of the image.
> 
> VOX:Image_Naxes
> --> pos.wcs.naxes
> specifying the number of image axes.
> 
> VOX:Image_Naxis
> --> pos.wcs.naxis
> with the array value giving the length in pixels of each image axis.
> 
> VOX:Image_Scale
> --> instr.scale
> with the array value giving the scale in degrees per pixel of each image
> axis.
> 
> VOX:Image_Format
> --> meta.code.mime
> specifying the MIME-type of the object associated with the image acref,
> 
> VOX:STC_CoordRefFrame
> --> pos.frame
> representing the coordinate system reference frame, selected from "ICRS",
> "FK5", "FK4", "ECL", "GAL", and "SGAL".
> 
> VOX:STC_CoordEquinox
> --> time.equinox
> representing the Equinox (not required for ICRS) of the coordinate system
> 
> VOX:WCS_CoordProjection
> --> pos.wcs.ctype
> the array value being the three-character code ("TAN", "ARC", "SIN", and so
> forth) specifying the celestial projection
> 
> VOX:WCS_CoordRefPixel
> --> pos.wcs.crpix
> with the array value specifying the image pixel coordinates of the WCS
> reference pixel. This is identical to "CRPIX" in FITS WCS.
> 
> VOX:WCS_CoordRefValue
> --> pos.wcs.crval
> with the array value specifying the world coordinates of the WCS reference
> pixel. This is identical to "CRVAL" in FITS WCS.
> 
> VOX:WCS_CDMatrix
> --> pos.wcs.cdmatrix
> with the array (matrix) value specifying the WCS CD matrix. This is
> identical to the "CD" term in FITS WCS, and defines the scale and rotation
> (among other things) of the image.
> 
> VOX:BandPass_ID
> --> instr.bandpass
> identifying the bandpass by name (e.g., "V", "SDSS_U", "K", "K-Band", etc.).
> 
> VOX:BandPass_Unit
> --> meta.unit
> identifying the units used to represent spectral values, selected from
> "meters", "hertz", and "keV".
> 
> VOX:BandPass_RefValue
> --> em.wl OR em.freq OR em.energy
> specifying the characteristic (reference) frequency, wavelength, or energy
> for the bandpass model.
> 
> VOX:BandPass_HiLimit
> --> em.wl;stat.max OR em.freq;stat.max OR em.energy;stat.max
> specifying the upper limit of the bandpass.
> 
> VOX:BandPass_LoLimit
> --> em.wl;stat.min OR em.freq;stat.min OR em.energy;stat.min
> specifying the lower limit of the bandpass.
> 
> VOX:Image_PixFlags
>  --> meta.code
> specifying the type of processing done by the image service to produce an
> output image pixel.
> 
> VOX:Image_AccessReference
> --> meta.ref.url
> specifying the URL to be used to access or retrieve the image.
> 
> VOX:Image_AccessRefTTL
> --> time.interval;stat.min
> specifying the minimum time to live in seconds of the access reference.
> 
> VOX:Image_FileSize
> --> phys.size;meta.file
> representing the actual or estimated size of the encoded image in bytes (not
> pixels!).
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From owner-ucd@eso.org  Wed Mar 24 21:56:37 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OKuMvR018830
	for <ucd-outgoing@mercury.hq.eso.org>; Wed, 24 Mar 2004 21:56:22 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2OKuMXu018829
	for ucd-outgoing; Wed, 24 Mar 2004 21:56:22 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OKuCvR018764;
	Wed, 24 Mar 2004 21:56:12 +0100 (MET)
Received: from [134.171.76.11] (vpn-11.hq.eso.org [134.171.76.11])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i2OKuCs28590;
	Wed, 24 Mar 2004 21:56:12 +0100 (MET)
In-Reply-To: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>
References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <AE7DEF0C-7DD5-11D8-A564-000A95D007D2@eso.org>
Content-Transfer-Encoding: 7bit
Cc: <dal@ivoa.net>, <ucd@ivoa.net>
From: Alberto Micol <Alberto.Micol@eso.org>
Subject: Re: New UCD1+ for SIA protocol
Date: Wed, 24 Mar 2004 21:56:11 +0100
To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mailer: Apple Mail (2.613)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


After a first glance: I like it! Well, this is not really helping 
anybody out there, is it?

Only two points (in the temporary absence of an established data model):

> VOX:Image_Scale
> --> instr.scale
> with the array value giving the scale in degrees per pixel of each 
> image
> axis.
>

Wouldn't it be better to have it as --> pos.wcs.scale ?
This parameter has to do with the way the data are sampled,
and any software could resample it (eg drizzle) onto a different grid
than the original instrumental pixel scale (and think of the case where
data from different instruments are mosaic'd together).
In the end the instrument (instr.) has nothing to do with the pixel 
scale.

And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix...
why do we need it? Probably for queries ...

Unless you meant the actual resolution (Rayleigh, seeing, etc)
Yet again in this case instr. is not the place to store it.

Actually, where is the resolution in this scheme?
Probably it was not in the SIAP, but I should read the SIAP specs again.


> VOX:Image_AccessReference
> --> meta.ref.url
> specifying the URL to be used to access or retrieve the image.

This is complex ... there could be various URLs associated to
the same image, e.g., to access the full product or only a preview;
but I need to read the SIAP doc again before insisting on this.

Alberto

From owner-ucd@eso.org  Wed Mar 24 22:32:17 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OLW2vR000344
	for <ucd-outgoing@mercury.hq.eso.org>; Wed, 24 Mar 2004 22:32:02 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2OLW2H4000343
	for ucd-outgoing; Wed, 24 Mar 2004 22:32:02 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OLVxvR000310;
	Wed, 24 Mar 2004 22:31:59 +0100 (MET)
Received: from mxsf23.cluster1.charter.net (mxsf23.cluster1.charter.net [209.225.28.223])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2OLVv3R014200;
	Wed, 24 Mar 2004 22:31:58 +0100 (CET)
Received: from mlaptop.localdomain (68-117-223-254.cpe.ga.charter.com [68.117.223.254])
	by mxsf23.cluster1.charter.net (8.12.10/8.12.8) with ESMTP id i2OLMXAv011672;
	Wed, 24 Mar 2004 16:22:34 -0500 (EST)
	(envelope-from brian.thomas@gsfc.nasa.gov)
From: Brian Thomas <brian.thomas@gsfc.nasa.gov>
To: Alberto Micol <Alberto.Micol@eso.org>
Subject: Re: New UCD1+ for SIA protocol
Date: Wed, 24 Mar 2004 16:21:17 -0500
User-Agent: KMail/1.6
References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> <AE7DEF0C-7DD5-11D8-A564-000A95D007D2@eso.org>
In-Reply-To: <AE7DEF0C-7DD5-11D8-A564-000A95D007D2@eso.org>
Cc: <dal@ivoa.net>, <ucd@ivoa.net>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200403241621.17502.brian.thomas@gsfc.nasa.gov>
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Brian Thomas <brian.thomas@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Wednesday 24 March 2004 03:56 pm, Alberto Micol wrote:
> After a first glance: I like it! Well, this is not really helping 
> anybody out there, is it?

	Well, I will try to push for this in the NOAO data model that
	our group is working on. 

	=b.t.

From owner-ucd@eso.org  Wed Mar 24 22:53:06 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OLqjvR009632
	for <ucd-outgoing@mercury.hq.eso.org>; Wed, 24 Mar 2004 22:52:45 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2OLqjBv009631
	for ucd-outgoing; Wed, 24 Mar 2004 22:52:45 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OLqgvR009620;
	Wed, 24 Mar 2004 22:52:42 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2OLqd3R016089;
	Wed, 24 Mar 2004 22:52:40 +0100 (CET)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i2OLqZs29058;
	Wed, 24 Mar 2004 14:52:35 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i2OLqXUr021770;
	Wed, 24 Mar 2004 14:52:34 -0700 (MST)
Date: Wed, 24 Mar 2004 14:52:33 -0700 (MST)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: Alberto Micol <Alberto.Micol@eso.org>
cc: Roy Williams <roy@cacr.caltech.edu>, <dal@ivoa.net>, <ucd@ivoa.net>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <AE7DEF0C-7DD5-11D8-A564-000A95D007D2@eso.org>
Message-ID: <Pine.LNX.4.44.0403241432010.12214-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7,
	BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37,
	QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Alberto -

On Wed, 24 Mar 2004, Alberto Micol wrote:
> Only two points (in the temporary absence of an established data model):
> 
> > VOX:Image_Scale
> > --> instr.scale
> > with the array value giving the scale in degrees per pixel of each 
> > image
> > axis.
> >
> 
> Wouldn't it be better to have it as --> pos.wcs.scale ?
> This parameter has to do with the way the data are sampled,
> and any software could resample it (eg drizzle) onto a different grid
> than the original instrumental pixel scale (and think of the case where
> data from different instruments are mosaic'd together).
> In the end the instrument (instr.) has nothing to do with the pixel 
> scale.
> 
> And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix...
> why do we need it? Probably for queries ...

All we are doing here is normalizing the UCDs for SIA - for V1.1 we would
prefer to minimize serious changes to the interface.  Anyway, although
the image scale can be computed from the CD matrix, 1) scale is a major
image attribute which we prefer to have readily available to the client
without having to process the WCS, 2) while the image scale is a required
parameter, the WCS is merely "strongly recommended" and data providers are
not required to provide it.  If the WCS is missing, it can be approximated
from the required image parameters, i.e., CRPIX the image center, CRVAL
is POS in IRCS coordinates, the image is assumed to be nonrotated, and
the CD matrix is thus defined by the naxis and scale values.

> Actually, where is the resolution in this scheme?  > Probably it was
not in the SIAP, but I should read the SIAP specs again.

SIA does not currently have the full sampling/bandpass data characterization
which we have discussed elsewhere.  At some point we would like to add this.
V1.1 is conceivable if it comes along fast enough.

> > VOX:Image_AccessReference
> > --> meta.ref.url
> > specifying the URL to be used to access or retrieve the image.
> 
> This is complex ... there could be various URLs associated to
> the same image, e.g., to access the full product or only a preview;
> but I need to read the SIAP doc again before insisting on this.

These each get a different row of the query response VOTable, hence each
has a different acref URL.  We have another proposal (again from Roy)
to define an optional logical name which can be used to tag each row in
the query result.  Rows which refer to the "same image" but differ only
in image format, bandpass, or whatever, would have the same logical name
to indicate that they are associated.

	- Doug

From owner-dal@eso.org  Wed Mar 24 23:19:54 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OMJbvR013819
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 24 Mar 2004 23:19:37 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2OMJbc5013818
	for dal-outgoing; Wed, 24 Mar 2004 23:19:37 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2OMJYvR013799;
	Wed, 24 Mar 2004 23:19:34 +0100 (MET)
Received: from [134.171.76.11] (vpn-11.hq.eso.org [134.171.76.11])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i2OMJYs01316;
	Wed, 24 Mar 2004 23:19:34 +0100 (MET)
In-Reply-To: <200403241621.17502.brian.thomas@gsfc.nasa.gov>
References: <02f401c411d0$3215b650$0c0ba8c0@cacr.caltech.edu> <AE7DEF0C-7DD5-11D8-A564-000A95D007D2@eso.org> <200403241621.17502.brian.thomas@gsfc.nasa.gov>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5441B66E-7DE1-11D8-A564-000A95D007D2@eso.org>
Content-Transfer-Encoding: 7bit
Cc: "<ucd@ivoa.net>" <ucd@ivoa.net>
From: Alberto Micol <Alberto.Micol@eso.org>
Subject: Re: New UCD1+ for SIA protocol
Date: Wed, 24 Mar 2004 23:19:34 +0100
To: "<dal@ivoa.net>" <dal@ivoa.net>
X-Mailer: Apple Mail (2.613)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Doug,

Yes, I completely agree with all you said, and understand the 
normalisation of UCDs;
my only objection was on the UCD name not to be linked to the 
instrument (instr.scale)
but to the pos.wcs. That is, I'm proposing:

instr.scale to be replaced by pos.wcs.scale

for all the reasons I already reported.
Sorry not to have been too clear the first time.

Alberto

PS: I understand from Brian that also my comment ("not helping anybody 
out there")
was misunderstood: I was in no way criticising the normalisation, which 
in fact I like.
It looks like this is not my day, better I close here and go to bed ...

From owner-dal@eso.org  Thu Mar 25 15:48:11 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PEiYiR010325
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 15:44:34 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PEiYO8010323
	for dal-outgoing; Thu, 25 Mar 2004 15:44:34 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PEiEiR010242;
	Thu, 25 Mar 2004 15:44:14 +0100 (MET)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PEi93R013337;
	Thu, 25 Mar 2004 15:44:10 +0100 (CET)
Received: from aria (aria.stsci.edu [130.167.236.125])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AJW64036;
	Thu, 25 Mar 2004 09:44:06 -0500 (EST)
Message-ID: <00cc01c41277$9ffe2e20$7deca782@stsci.edu>
From: "Robert Hanisch" <hanisch@stsci.edu>
To: "Doug Tody" <dtody@aoc.nrao.edu>, "Alberto Micol" <Alberto.Micol@eso.org>
Cc: "Roy Williams" <roy@cacr.caltech.edu>, <dal@ivoa.net>, <ucd@ivoa.net>
References: <Pine.LNX.4.44.0403241432010.12214-100000@oak>
Subject: Re: New UCD1+ for SIA protocol
Date: Thu, 25 Mar 2004 09:44:06 -0500
Organization: Space Telescope Science Institute
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Robert Hanisch" <hanisch@stsci.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

I just want to add my support for Alberto's objection to instr.scale -- I
think this could be very confusing.  The scale here is not an attribute of
the instrument, but of the image.  Glancing quickly through the UCD-UCD1+
mapping, however, I do not see a UCD that fits very well.

Is meta.bullshit going to stay?

Bob

----- Original Message ----- 
From: "Doug Tody" <dtody@aoc.nrao.edu>
To: "Alberto Micol" <Alberto.Micol@eso.org>
Cc: "Roy Williams" <roy@cacr.caltech.edu>; <dal@ivoa.net>; <ucd@ivoa.net>
Sent: Wednesday, March 24, 2004 4:52 PM
Subject: Re: New UCD1+ for SIA protocol


> Hi Alberto -
>
> On Wed, 24 Mar 2004, Alberto Micol wrote:
> > Only two points (in the temporary absence of an established data model):
> >
> > > VOX:Image_Scale
> > > --> instr.scale
> > > with the array value giving the scale in degrees per pixel of each
> > > image
> > > axis.
> > >
> >
> > Wouldn't it be better to have it as --> pos.wcs.scale ?
> > This parameter has to do with the way the data are sampled,
> > and any software could resample it (eg drizzle) onto a different grid
> > than the original instrumental pixel scale (and think of the case where
> > data from different instruments are mosaic'd together).
> > In the end the instrument (instr.) has nothing to do with the pixel
> > scale.
> >
> > And, anyway the pixel scale can be computed from the pos.wcs.cdmatrix...
> > why do we need it? Probably for queries ...
>
> All we are doing here is normalizing the UCDs for SIA - for V1.1 we would
> prefer to minimize serious changes to the interface.  Anyway, although
> the image scale can be computed from the CD matrix, 1) scale is a major
> image attribute which we prefer to have readily available to the client
> without having to process the WCS, 2) while the image scale is a required
> parameter, the WCS is merely "strongly recommended" and data providers are
> not required to provide it.  If the WCS is missing, it can be approximated
> from the required image parameters, i.e., CRPIX the image center, CRVAL
> is POS in IRCS coordinates, the image is assumed to be nonrotated, and
> the CD matrix is thus defined by the naxis and scale values.
>
> > Actually, where is the resolution in this scheme?  > Probably it was
> not in the SIAP, but I should read the SIAP specs again.
>
> SIA does not currently have the full sampling/bandpass data
characterization
> which we have discussed elsewhere.  At some point we would like to add
this.
> V1.1 is conceivable if it comes along fast enough.
>
> > > VOX:Image_AccessReference
> > > --> meta.ref.url
> > > specifying the URL to be used to access or retrieve the image.
> >
> > This is complex ... there could be various URLs associated to
> > the same image, e.g., to access the full product or only a preview;
> > but I need to read the SIAP doc again before insisting on this.
>
> These each get a different row of the query response VOTable, hence each
> has a different acref URL.  We have another proposal (again from Roy)
> to define an optional logical name which can be used to tag each row in
> the query result.  Rows which refer to the "same image" but differ only
> in image format, bandpass, or whatever, would have the same logical name
> to indicate that they are associated.
>
> - Doug
>
>

From owner-dal@eso.org  Thu Mar 25 16:14:15 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFDqiR018136
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 16:13:52 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PFDqSS018130
	for dal-outgoing; Thu, 25 Mar 2004 16:13:52 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFBnir017475;
	Thu, 25 Mar 2004 16:13:38 +0100 (MET)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PF4MmW028059;
	Thu, 25 Mar 2004 16:04:23 +0100 (CET)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i2PF4BHI014386;
	Thu, 25 Mar 2004 08:04:13 -0700
Date: Thu, 25 Mar 2004 08:04:09 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Robert Hanisch <hanisch@stsci.edu>
cc: Alberto Micol <Alberto.Micol@eso.org>, Roy Williams <roy@cacr.caltech.edu>,
   <dal@ivoa.net>, <ucd@ivoa.net>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu>
Message-ID: <Pine.LNX.4.44.0403250755000.2369-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Thu, 25 Mar 2004, Robert Hanisch wrote:
> I just want to add my support for Alberto's objection to instr.scale -- I
> think this could be very confusing.  The scale here is not an attribute of
> the instrument, but of the image.  Glancing quickly through the UCD-UCD1+
> mapping, however, I do not see a UCD that fits very well.

I also agree, this is the image scale not an instrument attribute.

A larger point here is that in the process of normalizing the UCDS in
SIA V1.1, we also plan to introduce UTYPE.  The recommendation for folks
writing software interfaces to interpret SIA tables will be to use UTYPE
to identify the formally defined elements of the interface.  This is very
straightforward whereas UCD is not; we can evolve UCD independently and
our interfaces will not break.  Hence it is up to the UCD folks to assign
the best UCDs for these fields, and if we have to adjust or generalize them
later we will be able do so.

In general I think UCD should be used for hard things like inference,
semantic associations, smart queries, etc.  UTYPE is much simpler and is
what we need to identify interface elements in a straightforward manner.

	- Doug

From owner-ucd@eso.org  Thu Mar 25 16:15:00 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFEWiR018348
	for <ucd-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 16:14:32 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PFEWA6018344
	for ucd-outgoing; Thu, 25 Mar 2004 16:14:32 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFEHiR018271;
	Thu, 25 Mar 2004 16:14:17 +0100 (MET)
Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PFEFmW028462;
	Thu, 25 Mar 2004 16:14:15 +0100 (CET)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1B6WYg-000COW-7Y; Thu, 25 Mar 2004 15:14:14 +0000
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1B6WYg-0000MS-00; Thu, 25 Mar 2004 15:14:14 +0000
Date: Thu, 25 Mar 2004 15:14:13 +0000 (GMT)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Robert Hanisch <hanisch@stsci.edu>
cc: Doug Tody <dtody@aoc.nrao.edu>, Alberto Micol <Alberto.Micol@eso.org>,
   Roy Williams <roy@cacr.caltech.edu>, dal@ivoa.net, ucd@ivoa.net
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu>
Message-ID: <Pine.GSO.4.53.0403251500140.26102@adikia>
References: <Pine.LNX.4.44.0403241432010.12214-100000@oak>
 <00cc01c41277$9ffe2e20$7deca782@stsci.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1B6WYg-000COW-7Y*CN.rzMY6nNo*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Bob Hanisch wrote
> I just want to add my support for Alberto's objection to instr.scale -- I
> think this could be very confusing.  The scale here is not an attribute of
> the instrument, but of the image.  Glancing quickly through the UCD-UCD1+
> mapping, however, I do not see a UCD that fits very well.

Alberto (I think) wrote
> > Actually, where is the resolution in this scheme?  > Probably it was
> not in the SIAP, but I should read the SIAP specs again.

To underline these points, I think thaat there may be a tendency to think
of images as products of instruments using pixel detectors, where the
pixel scale of the instrument determines the resolution of the image and
the sampling interval of the image.  But of course that ain't necessarily
so.  As has been pointed out, data processing can change the image pixel
size of even CCD images let alone other forms of data. The resolution is
determined by the PSF, but even that means different things in different
regimes.   Both pixel size and resolution are variable e.g. by weighting
radio data.

Hence for describing images you need an image pixel size.

Resolution is tricker since even in a single image that can be brightness
dependent.  In the Registry we would use a range but in describing images
I think that the choices are

1) Just use image pixel size and assume that everyone uses something close
to the convention of 3 pixels across a resolution element most of the time
(but as resolution is unspecified the user will have to think about it and
hence will not be misled).  This is probably best for images but maybe
not for catalogue data.

2) Use a 'characteristic resolution'.  However, that is problematic for
images as this may not be specified in the FITS header (e.g. in radio
images the restoring beam size is usually in there but can be buried deep
in the history).  However it is often what is given in catalogues.

cheers

a
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).



From owner-dal@eso.org  Thu Mar 25 16:39:00 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFcciR025027
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 16:38:38 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PFcbT7025021
	for dal-outgoing; Thu, 25 Mar 2004 16:38:37 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFThjT022260;
	Thu, 25 Mar 2004 16:38:25 +0100 (MET)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PFHC3R014810;
	Thu, 25 Mar 2004 16:17:12 +0100 (CET)
Received: from Ropy (dsl-64-30-223-60.lcinet.net [64.30.223.60])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2PFH8k4026888
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Thu, 25 Mar 2004 07:17:09 -0800
Message-ID: <020801c4127c$3bf4a530$7201a8c0@Ropy>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: "Robert Hanisch" <hanisch@stsci.edu>, "Doug Tody" <dtody@aoc.nrao.edu>,
   "Alberto Micol" <Alberto.Micol@eso.org>
Cc: <dal@ivoa.net>, <ucd@ivoa.net>
References: <Pine.LNX.4.44.0403241432010.12214-100000@oak> <00cc01c41277$9ffe2e20$7deca782@stsci.edu>
Subject: Re: New UCD1+ for SIA protocol
Date: Thu, 25 Mar 2004 07:17:04 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> Is meta.bullshit going to stay?

Definitely.

From owner-ucd@eso.org  Thu Mar 25 16:45:45 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFjSiR026825
	for <ucd-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 16:45:28 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PFjSE0026824
	for ucd-outgoing; Thu, 25 Mar 2004 16:45:28 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFjFiR026767;
	Thu, 25 Mar 2004 16:45:15 +0100 (MET)
Received: from E1000.artov.rm.cnr.it (saturn.rm.iasf.cnr.it [150.146.136.11])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PFj53R016057;
	Thu, 25 Mar 2004 16:45:08 +0100 (CET)
Received: from saturn.rm.iasf.cnr.it(150.146.136.11) by E1000.artov.rm.cnr.it via csmap 
	 id 96e8c404_7e73_11d8_89dd_0002b3da0f69_31452;
	Thu, 25 Mar 2004 16:46:36 +0100 (CET)
Received: from apm.rm.iasf.cnr.it (apm.rm.iasf.cnr.it [150.146.136.115])
	by saturn.rm.iasf.cnr.it (8.11.3/8.11.3) with ESMTP id i2PFl0P11634;
	Thu, 25 Mar 2004 16:47:00 +0100
Date: Thu, 25 Mar 2004 16:45:07 +0100 (ora solare Europa occidentale)
From: Andrea Preite Martinez <andrea@rm.iasf.cnr.it>
To: Robert Hanisch <hanisch@stsci.edu>
cc: Doug Tody <dtody@aoc.nrao.edu>, Alberto Micol <Alberto.Micol@eso.org>,
   Roy Williams <roy@cacr.caltech.edu>, dal@ivoa.net, ucd@ivoa.net
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <00cc01c41277$9ffe2e20$7deca782@stsci.edu>
Message-ID: <Pine.WNT.4.58.0403251641480.1380@apm.rm.iasf.cnr.it>
References: <Pine.LNX.4.44.0403241432010.12214-100000@oak>
 <00cc01c41277$9ffe2e20$7deca782@stsci.edu>
X-X-Sender: andrea@saturn.rm.iasf.cnr.it
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Andrea Preite Martinez <andrea@rm.iasf.cnr.it>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

A comment on

1) VOX:Image_Scale --> instr.scale
and

2) UCD1+:meta.bullshit (Bob's message)

1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are
present in instr.scale and obs.image . To me the concept of scale in this
context is more important than the concept of image, then I supported
"instr.scale".
A much better alternative could be the definition of the new ucd1+:
obs.image.scale

2. While examining all the tables and columns in Vizier I came across 2 or
3 columns whose names and descriptions were so cryptical that even going to
the original papers I could not understand the nature of what the author(s)
had in mind to describe. My limitation, of course. I then marked those
cases with this (probably a bit offensive) tag.
The file ~/ucd1-ucd1p.txt was then automatically generated from a much
bigger/detailed file, and the tag slipped through. If and when we will move
to ucd1+, I'll remove it.

Andrea
==============================================================================
Andrea Preite Martinez                  andrea@rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From owner-dal@eso.org  Thu Mar 25 16:52:54 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFqaiR028698
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 16:52:36 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PFqa1R028695
	for dal-outgoing; Thu, 25 Mar 2004 16:52:36 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFqTiR028660;
	Thu, 25 Mar 2004 16:52:29 +0100 (MET)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PFqQmW000179;
	Thu, 25 Mar 2004 16:52:27 +0100 (CET)
Received: from aria (aria.stsci.edu [130.167.236.125])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AJW68556;
	Thu, 25 Mar 2004 10:52:09 -0500 (EST)
Message-ID: <018101c41281$219f5db0$7deca782@stsci.edu>
From: "Robert Hanisch" <hanisch@stsci.edu>
To: "Andrea Preite Martinez" <andrea@rm.iasf.cnr.it>
Cc: "Doug Tody" <dtody@aoc.nrao.edu>, "Alberto Micol" <Alberto.Micol@eso.org>,
   "Roy Williams" <roy@cacr.caltech.edu>, <dal@ivoa.net>, <ucd@ivoa.net>
References: <Pine.LNX.4.44.0403241432010.12214-100000@oak> <00cc01c41277$9ffe2e20$7deca782@stsci.edu> <Pine.WNT.4.58.0403251641480.1380@apm.rm.iasf.cnr.it>
Subject: Re: New UCD1+ for SIA protocol
Date: Thu, 25 Mar 2004 10:52:09 -0500
Organization: Space Telescope Science Institute
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Robert Hanisch" <hanisch@stsci.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


----- Original Message ----- 
From: "Andrea Preite Martinez" <andrea@rm.iasf.cnr.it>
To: "Robert Hanisch" <hanisch@stsci.edu>
Cc: "Doug Tody" <dtody@aoc.nrao.edu>; "Alberto Micol"
<Alberto.Micol@eso.org>; "Roy Williams" <roy@cacr.caltech.edu>;
<dal@ivoa.net>; <ucd@ivoa.net>
Sent: Thursday, March 25, 2004 10:45 AM
Subject: Re: New UCD1+ for SIA protocol


> A comment on
>
> 1) VOX:Image_Scale --> instr.scale
> and
>
> 2) UCD1+:meta.bullshit (Bob's message)
>
> 1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are
> present in instr.scale and obs.image . To me the concept of scale in this
> context is more important than the concept of image, then I supported
> "instr.scale".
> A much better alternative could be the definition of the new ucd1+:
> obs.image.scale

Yes, much better!


> 2. While examining all the tables and columns in Vizier I came across 2 or
> 3 columns whose names and descriptions were so cryptical that even going
to
> the original papers I could not understand the nature of what the
author(s)
> had in mind to describe. My limitation, of course. I then marked those
> cases with this (probably a bit offensive) tag.
> The file ~/ucd1-ucd1p.txt was then automatically generated from a much
> bigger/detailed file, and the tag slipped through. If and when we will
move
> to ucd1+, I'll remove it.

How about meta.unknown?

Not that I am so easy to offend, mind you, but...

Bob


>
> Andrea
>
============================================================================
==
> Andrea Preite Martinez                  andrea@rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma
>
============================================================================
==
>
>
>

From owner-ucd@eso.org  Thu Mar 25 17:00:06 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFxiiR000327
	for <ucd-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 16:59:44 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PFxiqP000322
	for ucd-outgoing; Thu, 25 Mar 2004 16:59:44 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PFxQiR000240;
	Thu, 25 Mar 2004 16:59:26 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PFxOmW000599;
	Thu, 25 Mar 2004 16:59:24 +0100 (CET)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i2PFxHs26098;
	Thu, 25 Mar 2004 08:59:18 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i2PFxGUr011535;
	Thu, 25 Mar 2004 08:59:16 -0700 (MST)
Date: Thu, 25 Mar 2004 08:59:16 -0700 (MST)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net, <ucd@ivoa.net>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <Pine.LNX.4.44.0403250755000.2369-100000@lepus.tuc.noao.edu>
Message-ID: <Pine.LNX.4.44.0403250852430.12214-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7,
	BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37,
	QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Taking this one step further: if we start inventing UCDs which are nothing
more than the names of data model attributes, this may indicate that
something is wrong.  Perhaps what we should be doing is using UTYPE
to define the data model attribute or interface element (if there is one),
and UCD to say something about the quantity given as the value.
For example, if the UTYPE is something like image.scale, then the UCD
might define the type of physical quantity including units.  Currently
we try to fix the quantity/units, but there are cases where this needs
to vary even though we are talking about a single data model attribute.

	- Doug





On Thu, 25 Mar 2004, Doug Tody wrote:

> On Thu, 25 Mar 2004, Robert Hanisch wrote:
> > I just want to add my support for Alberto's objection to instr.scale -- I
> > think this could be very confusing.  The scale here is not an attribute of
> > the instrument, but of the image.  Glancing quickly through the UCD-UCD1+
> > mapping, however, I do not see a UCD that fits very well.
> 
> I also agree, this is the image scale not an instrument attribute.
> 
> A larger point here is that in the process of normalizing the UCDS in
> SIA V1.1, we also plan to introduce UTYPE.  The recommendation for folks
> writing software interfaces to interpret SIA tables will be to use UTYPE
> to identify the formally defined elements of the interface.  This is very
> straightforward whereas UCD is not; we can evolve UCD independently and
> our interfaces will not break.  Hence it is up to the UCD folks to assign
> the best UCDs for these fields, and if we have to adjust or generalize them
> later we will be able do so.
> 
> In general I think UCD should be used for hard things like inference,
> semantic associations, smart queries, etc.  UTYPE is much simpler and is
> what we need to identify interface elements in a straightforward manner.
> 
> 	- Doug
> 
> 

From owner-ucd@eso.org  Thu Mar 25 17:00:45 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PG0OiR000674
	for <ucd-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 17:00:24 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PG0O47000670
	for ucd-outgoing; Thu, 25 Mar 2004 17:00:24 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PG0BiR000588;
	Thu, 25 Mar 2004 17:00:11 +0100 (MET)
Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PG09mW000639;
	Thu, 25 Mar 2004 17:00:09 +0100 (CET)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1B6XH6-000Iw3-E0; Thu, 25 Mar 2004 16:00:08 +0000
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1B6XH6-0000zT-00; Thu, 25 Mar 2004 16:00:08 +0000
Date: Thu, 25 Mar 2004 16:00:08 +0000 (GMT)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Andrea Preite Martinez <andrea@rm.iasf.cnr.it>
cc: Robert Hanisch <hanisch@stsci.edu>, Doug Tody <dtody@aoc.nrao.edu>,
   Alberto Micol <Alberto.Micol@eso.org>, Roy Williams <roy@cacr.caltech.edu>,
   dal@ivoa.net, ucd@ivoa.net
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <Pine.WNT.4.58.0403251641480.1380@apm.rm.iasf.cnr.it>
Message-ID: <Pine.GSO.4.53.0403251558010.26102@adikia>
References: <Pine.LNX.4.44.0403241432010.12214-100000@oak>
 <00cc01c41277$9ffe2e20$7deca782@stsci.edu> <Pine.WNT.4.58.0403251641480.1380@apm.rm.iasf.cnr.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1B6XH6-000Iw3-E0*edTjeeCqleA*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

>
> 1) VOX:Image_Scale --> instr.scale
>
> A much better alternative could be the definition of the new ucd1+:
> obs.image.scale

That still suggest to me that the scale is inherant to the observations -
but it is better

> 2) UCD1+:meta.bullshit (Bob's message)

> bigger/detailed file, and the tag slipped through. If and when we will move
> to ucd1+, I'll remove it.
Or jsut wait until your critics stop talking bullshit?

You and Roy and Sebastien have done a pretty good job if people can only
find 1.5 ucd1+'s to complain about!

a


From owner-dal@eso.org  Thu Mar 25 17:02:32 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PG2EiR001477
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 17:02:15 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PG2E3A001475
	for dal-outgoing; Thu, 25 Mar 2004 17:02:14 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PG1ciR001211;
	Thu, 25 Mar 2004 17:01:38 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PG1amW000685;
	Thu, 25 Mar 2004 17:01:37 +0100 (CET)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id i2PG1Xph012044;
	Thu, 25 Mar 2004 11:01:33 -0500 (EST)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id i2PG1VKf007368;
	Thu, 25 Mar 2004 11:01:31 -0500 (EST)
Date: Thu, 25 Mar 2004 11:01:31 -0500 (EST)
Message-Id: <200403251601.i2PG1VKf007368@urania.cfa.harvard.edu>
To: ucd@ivoa.net, roy@cacr.caltech.edu, andrea@rm.iasf.cnr.it,
   alberto.micol@eso.org, hanisch@stsci.edu, dal@ivoa.net, dtody@aoc.nrao.edu
Subject: Re: New UCD1+ for SIA protocol
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Apologies if this is already covered, I missed some emails..
My biggest problem is "pos.wcs" which generalizes poorly.
Seems to me that naxis and naxes are
properties of the pixels, and indeed of the image and not of pos itself.
What if you have an x,y,time cube? I would argue it would be

 obs.image.naxes
 obs.image.naxis

or perhaps
 obs.image.wcs.naxes
 obs.image.wcs.naxis

(or array.naxes or whatever the top level thing, but not pos)

but not
 pos.naxes   = 2
 time.naxes  = 1
 pos.naxis = 512 512
 time.naxis =  30

Similarly, the other wcs.* should probably be image.wcs.*
not pos.wcs.* ?

I agree with others comments about instr.scale;
Should be
 image.wcs.scale

I am generally confused about what is in "wcs" and what
is not:  "pos.frame" not part of wcs, but "pos.wcs.naxes" is?

>  > meta.bullshit
>  meta.unknown?

I think the first is a more accurate description; how about
   meta.badly_defined
or
   meta.obscure
:-)


 - Jonathan

From owner-ucd@eso.org  Thu Mar 25 17:05:54 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PG5NiR002573
	for <ucd-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 17:05:23 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PG5NGr002571
	for ucd-outgoing; Thu, 25 Mar 2004 17:05:23 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PG51iR002426;
	Thu, 25 Mar 2004 17:05:01 +0100 (MET)
Received: from eso.org (st14.hq.eso.org [134.171.10.25])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i2PG51s23577;
	Thu, 25 Mar 2004 17:05:01 +0100 (MET)
Message-ID: <4063032C.2090803@eso.org>
Date: Thu, 25 Mar 2004 17:05:00 +0100
From: Alberto Micol <Alberto.Micol@eso.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andrea Preite Martinez <andrea@rm.iasf.cnr.it>
CC: dal@ivoa.net, ucd@ivoa.net
Subject: Re: New UCD1+ for SIA protocol
References: <Pine.LNX.4.44.0403241432010.12214-100000@oak> <00cc01c41277$9ffe2e20$7deca782@stsci.edu> <Pine.WNT.4.58.0403251641480.1380@apm.rm.iasf.cnr.it>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


>1. In the list of ucd1+ that I derived, the atoms "image" and "scale" are
>present in instr.scale and obs.image . To me the concept of scale in this
>context is more important than the concept of image, then I supported
>"instr.scale".
>A much better alternative could be the definition of the new ucd1+:
>obs.image.scale
>

Sorry Andrea,

But if we go for obs.image.scale
then one would also think that the following should exist:

obs.spectrum.scale

And furthermore, personally if I see a scale at that level
then I also expect:

obs.image.wcs.ctype
obs.image.wcs.crpix
obs.image.wcs.crval
obs.image.wcs.cdmatrix
etc.
and similarly for obs.spectrum ...


Hence, I like much better the pos than the obs.image
because it is more generic.

So in the end I like much better:

pos.wcs.ctype
pos.wcs.crval
pos.wcs.scale  !!!
etc etc

because we can reuse it in many different contexts (spectra, images etc).
Let's keep together all the "how is the dataset sampled?" elements under
the same UCD (pos) and not let them spread under different ones.

Alberto
PS: Yes Anita they did a good job indeed!


From owner-dal@eso.org  Thu Mar 25 18:49:22 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PHmuiR025107
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 18:48:56 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PHmt8J025106
	for dal-outgoing; Thu, 25 Mar 2004 18:48:55 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PHmfiR025029;
	Thu, 25 Mar 2004 18:48:41 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PHmc3R021259;
	Thu, 25 Mar 2004 18:48:39 +0100 (CET)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i2PHjMs02939;
	Thu, 25 Mar 2004 10:45:22 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i2PHjKUr001828;
	Thu, 25 Mar 2004 10:45:20 -0700 (MST)
Date: Thu, 25 Mar 2004 10:45:20 -0700 (MST)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: Anita Richards <amsr@jb.man.ac.uk>
cc: dal@ivoa.net, <ucd@ivoa.net>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <Pine.GSO.4.53.0403251558010.26102@adikia>
Message-ID: <Pine.LNX.4.44.0403250955240.12214-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7,
	BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37,
	QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Thu, 25 Mar 2004, Anita Richards wrote:

> > 1) VOX:Image_Scale --> instr.scale
> >
> > A much better alternative could be the definition of the new ucd1+:
> > obs.image.scale
> 
> That still suggest to me that the scale is inherant to the observations -
> but it is better

This is a general issue with what we are calling the "observation"
data model.  This may be just a naming issue but I worry that we may try
to describe actual observations.

What we really need to do for VO is characterize the physical attributes
of a dataset.  A dataset may be a calibrated observation, or it may be
the result of an arbitrary amount of processing of multiple observations,
or it may be synthetic data.  It does not matter how the dataset was
generated if we describe only the physical attributes of the actual final
dataset we are dealing with.  Scale and resolution are good examples of
such physical attributes.

For VO data analysis where we may need to deal uniformly with data from
many origins, physical dataset characterization is what is needed.  At this
level we should not have any information about the actual observations,
instrument characteristics, etc., (if any) used to produce the dataset.
Such information may be present in each individual dataset, and can be
useful to fully understand individual datasets, but is not very useful
for automated processing of data from many origins.

A simple example is exposure time.  While a typical attribute of an
individual original observation, it tells us almost nothing about an
arbitrary dataset.  To understand what this means we would have to
understand the full instrumental model and configuration, and all the
post-processing done to get to the final dataset we are actually looking at.
The related physical dataset attributes are the sampling and coverage in
time of the final (possibly aggregate) dataset, and some physical measure
of the limiting flux of a signal detected by the dataset.


From owner-ucd@eso.org  Thu Mar 25 19:22:21 2004
Return-Path: <owner-ucd@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PIM5iR000863
	for <ucd-outgoing@mercury.hq.eso.org>; Thu, 25 Mar 2004 19:22:06 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2PIM56T000862
	for ucd-outgoing; Thu, 25 Mar 2004 19:22:05 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-ucd@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2PIM2iR000841
	for <ucd@ivoa.net>; Thu, 25 Mar 2004 19:22:02 +0100 (MET)
Received: from apollo.le.ac.uk (ntp2b.le.ac.uk [143.210.16.125])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2PIM03R022517
	for <ucd@ivoa.net>; Thu, 25 Mar 2004 19:22:00 +0100 (CET)
Received: from [143.210.36.58] (helo=mail.star.le.ac.uk)
	by apollo.le.ac.uk with smtp (Exim 4.30)
	id 1B6ZUN-0002QL-Lb
	for ucd@ivoa.net; Thu, 25 Mar 2004 18:21:59 +0000
Received: (qmail 22101 invoked from network); 25 Mar 2004 18:22:20 -0000
Received: from sparky.star.le.ac.uk (143.210.36.10)
  by mail.star.le.ac.uk with SMTP; 25 Mar 2004 18:22:20 -0000
Date: Thu, 25 Mar 2004 18:22:20 +0000 (GMT)
From: "Patricio F. Ortiz" <pfo@star.le.ac.uk>
To: Doug Tody <dtody@aoc.nrao.edu>
cc: Anita Richards <amsr@jb.man.ac.uk>, <dal@ivoa.net>, <ucd@ivoa.net>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <Pine.LNX.4.44.0403250955240.12214-100000@oak>
Message-ID: <Pine.GSO.4.44L0.0403251800250.2975-100000@sparky.star.le.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-ucd@eso.org
Precedence: bulk
Reply-To: "Patricio F. Ortiz" <pfo@star.le.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Doug,

I fully agree with you, I think you hit the nail, it is the dataset
that the user gets what needs proper description, regardless of what's
been done to reach this result.

A dataset has an angular scale ("/pix) or a linear scale (km/pix, eg,
solar or planetary images), the dataset's origin may be real
observations or simulations, simple observations (classical CCD image),
mosaics, images based on radio data, multiwavelength composites, whatever.
Scales can be degraded or modified from the initial products (eg, DSS)

As you said, something similar happens when describing the time
coverage. Quantities which make sense to individual observations don't
necessariry apply to final products (datasets), for instance,
exposure_time != end_of_exposure - start_of_exposure in a dataset which
does not represent an individual observation.

Color composite images are another example of a final product where the
individual observations' parameters may vary considerably, talking about
instrument.scale or obs.scale does not seem appropriate anymore. At the
time of the construction of UCD0 it did make sense to group these items (read
drop these items) in the "instrumental" category. That doesn't apply
any longer.

Cheers,

Patricio

On Thu, 25 Mar 2004, Doug Tody wrote:
> On Thu, 25 Mar 2004, Anita Richards wrote:
>
> > > 1) VOX:Image_Scale --> instr.scale
> > >
> > > A much better alternative could be the definition of the new ucd1+:
> > > obs.image.scale
> >
> > That still suggest to me that the scale is inherant to the observations -
> > but it is better
>
> This is a general issue with what we are calling the "observation"
> data model.  This may be just a naming issue but I worry that we may try
> to describe actual observations.
>
> What we really need to do for VO is characterize the physical attributes
> of a dataset.  A dataset may be a calibrated observation, or it may be
> the result of an arbitrary amount of processing of multiple observations,
> or it may be synthetic data.  It does not matter how the dataset was
> generated if we describe only the physical attributes of the actual final
> dataset we are dealing with.  Scale and resolution are good examples of
> such physical attributes.
>
> For VO data analysis where we may need to deal uniformly with data from
> many origins, physical dataset characterization is what is needed.  At this
> level we should not have any information about the actual observations,
> instrument characteristics, etc., (if any) used to produce the dataset.
> Such information may be present in each individual dataset, and can be
> useful to fully understand individual datasets, but is not very useful
> for automated processing of data from many origins.
>
> A simple example is exposure time.  While a typical attribute of an
> individual original observation, it tells us almost nothing about an
> arbitrary dataset.  To understand what this means we would have to
> understand the full instrumental model and configuration, and all the
> post-processing done to get to the final dataset we are actually looking at.
> The related physical dataset attributes are the sampling and coverage in
> time of the final (possibly aggregate) dataset, and some physical measure
> of the limiting flux of a signal detected by the dataset.

---
Patricio F. Ortiz			pfo@star.le.ac.uk
AstroGrid project
Department of Physics and Astronomy
University of Leicester			Tel: +44 (0)116 252 2015
LE1 7RH, UK

From owner-dal@eso.org  Fri Mar 26 18:52:21 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2QHpkEJ000625
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 26 Mar 2004 18:51:46 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2QHpkt7000624
	for dal-outgoing; Fri, 26 Mar 2004 18:51:46 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2QHpfEJ000600;
	Fri, 26 Mar 2004 18:51:41 +0100 (MET)
Received: from newb6.u-strasbg.fr (newb6.u-strasbg.fr [130.79.128.16])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2QHpd3R003877;
	Fri, 26 Mar 2004 18:51:39 +0100 (CET)
Received: from astro.u-strasbg.fr (localhost [127.0.0.1])
	by newb6.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id SAA05257;
	Fri, 26 Mar 2004 18:50:50 +0100 (MET)
Message-ID: <40646D7A.9EE207DD@astro.u-strasbg.fr>
Date: Fri, 26 Mar 2004 18:50:50 +0100
From: Sebastien Derriere <derriere@newb6.u-strasbg.fr>
Organization: Observatoire de Strasbourg
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Arnold Rots <arots@head.cfa.harvard.edu>
CC: dal@ivoa.net, ucd@ivoa.net
Subject: Re: New UCD1+ for SIA protocol
References: <200403241946.i2OJkEu1003422@xebec.cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-MailScanner-Astro: Message analyse non infecte par sophos sur astro.u-strasbg.fr
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Sebastien Derriere <derriere@newb6.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Arnold Rots wrote:
> 
> SIAP 1.1:
> 
> I had asked that SCORE (used to be GRADE) be included in the list of
> optional input and output parameters and there seemed to be agreement
> that it is a useful thing.

  Hello Arnold,

  If this SCORE is added to the parameters, there is one UCD that 
could be used:   meta.code.qual is a quality/precision/reliability
index or flag.

Sebastien.

-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere@astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France

From owner-dal@eso.org  Fri Mar 26 21:35:45 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2QKZQEJ012285
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 26 Mar 2004 21:35:26 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2QKZQwd012284
	for dal-outgoing; Fri, 26 Mar 2004 21:35:26 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2QKZIEJ012253;
	Fri, 26 Mar 2004 21:35:18 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2QKZG3R009198;
	Fri, 26 Mar 2004 21:35:16 +0100 (CET)
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head.cfa.harvard.edu (d/w) with ESMTP id i2QKZCph022151;
	Fri, 26 Mar 2004 15:35:12 -0500 (EST)
From: Arnold Rots <arots@head.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id i2QKZCM4000824;
	Fri, 26 Mar 2004 15:35:12 -0500 (EST)
Message-Id: <200403262035.i2QKZCM4000824@xebec.cfa.harvard.edu>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <40646D7A.9EE207DD@astro.u-strasbg.fr>
To: Sebastien Derriere <derriere@newb6.u-strasbg.fr>
Date: Fri, 26 Mar 2004 15:35:11 -0500 (EST)
CC: Arnold Rots <arots@head.cfa.harvard.edu>, dal@ivoa.net, ucd@ivoa.net
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Arnold Rots <arots@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Sebastien,

Yes, I had noticed that one but thought that maybe it should be
preserved for a more formal and precise quality or, more specifically,
the quality of the data.  For instance, when you have two exposures,
one of 1000 s and one of 100000 s, the score of the latter may be
higher, even though the quality of the data in the former may be better.
What it amounts to is that score and quality are notr quite the same
concept.  Data quality is a component but not the only thing that 
goes into a score.

  - Arnold

Sebastien Derriere wrote:
> Arnold Rots wrote:
> > 
> > SIAP 1.1:
> > 
> > I had asked that SCORE (used to be GRADE) be included in the list of
> > optional input and output parameters and there seemed to be agreement
> > that it is a useful thing.
> 
>   Hello Arnold,
> 
>   If this SCORE is added to the parameters, there is one UCD that 
> could be used:   meta.code.qual is a quality/precision/reliability
> index or flag.
> 
> Sebastien.
> 
> -- 
>     _______
>    /  ~   /, Sebastien Derriere   mailto:derriere@astro.u-strasbg.fr
>   / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
>  /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
> (______(/    F-67000 Strasbourg  France
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From owner-dal@eso.org  Mon Mar 29 15:33:49 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2TDXEGl013275
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 29 Mar 2004 15:33:14 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2TDXDiV013271
	for dal-outgoing; Mon, 29 Mar 2004 15:33:13 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2TDX0Gl013127;
	Mon, 29 Mar 2004 15:33:00 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i2TDX0s09190;
	Mon, 29 Mar 2004 15:33:00 +0200 (MEST)
Message-ID: <4068259A.30901@eso.org>
Date: Mon, 29 Mar 2004 15:33:14 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Ray Plante <rplante@poplar.ncsa.uiuc.edu>
CC: dal@ivoa.net, Doug Tody <dtody@nrao.edu>
Subject: scope of SIA schema
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi Ray,

What's the scope of the SIA schema definition http://www.ivoa.net/xml/SIA/ ?

I simply assume that you were involved producing it and therefore my question 
to you:

In which context should it be used?
- When encoding SIA query mode response?
- As response to a registry query?

And, how about extending it to work also with SSA? The number of additional 
elements should be marginal.

The main issue I'm not clear about is the following, but I'm sure you and Doug 
have thought of it before:

The SIA query mode (and presumably SSA query mode) returns a VOTable that 
requires special client software to parse it. The question is whether we can 
avoid this in future by re-using things like the VOResource in the SIA/SSA 
query mode context. It seems, however, that the given SIA schema is weaving in 
what I would call registry-type components (VOResource, VODataService) PLUS SIA 
specific elements. The presence of the Schema suggests that SIA servers and 
clients need to support all of it(?)

Maybe I'm confusing things here, but anyway, the SIA and SSA docs that we are 
preparing for the upcoming NVO + interop meetings need to describe such 
dependencies.

Markus

From owner-dal@eso.org  Mon Mar 29 19:51:42 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2THpJGl013058
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 29 Mar 2004 19:51:19 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i2THpJ2u013057
	for dal-outgoing; Mon, 29 Mar 2004 19:51:19 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i2THp4Gl012989
	for <dal@ivoa.net>; Mon, 29 Mar 2004 19:51:04 +0200 (MEST)
Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i2THp23R004796
	for <dal@ivoa.net>; Mon, 29 Mar 2004 19:51:03 +0200 (CEST)
Received: from localhost (rplante@localhost)
	by poplar.ncsa.uiuc.edu (8.11.6/8.11.6) with ESMTP id i2THp1q17266
	for <dal@ivoa.net>; Mon, 29 Mar 2004 11:51:01 -0600
Date: Mon, 29 Mar 2004 11:51:01 -0600 (CST)
From: Ray Plante <rplante@poplar.ncsa.uiuc.edu>
To: dal@ivoa.net
Subject: Re: scope of SIA schema
In-Reply-To: <4068259A.30901@eso.org>
Message-ID: <Pine.LNX.4.44.0403291111340.8361-100000@poplar.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ray Plante <rplante@poplar.ncsa.uiuc.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hey Markus,


On Mon, 29 Mar 2004, Markus Dolensky wrote:
> What's the scope of the SIA schema definition http://www.ivoa.net/xml/SIA/ ?
> 
> I simply assume that you were involved producing it and therefore my question 
> to you:
> 
> In which context should it be used?
> - When encoding SIA query mode response?
> - As response to a registry query?

I'm glad you noticed this, and I'm happy to advise as necessary for SSA.  

That SIA schema is specifically for describing SIA services within the 
registry.  It is an extension of the VOResource schema specific for SIA.  
Since SIA responds with a VOTable, it is not intended to be part of the 
SIA query response.  

The idea is that every standard service will have a set of metadata for 
describing the capabilities of an implementation which are specific for 
that type of service.  For SIA, this metadata is described in concept in 
section 7.2 ("Registering a Compliant Service").  SSA will have its own 
set (though may be very similar to SIA) which should be similarly 
described in the SSA spec.  The VOResource schema has a special element 
for including this specialized metadata called "Capabilities".  The SIA 
schema extends this element to add the SIA metadata; as part of this 
extension this element is "renamed" to "SimpleImageAccess" (in XML-speak, 
it is defined as being in the same substitution group).  

For an example see 
http://nvo.ncsa.uiuc.edu/cgi-bin/nvo/oai.pl?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo%3A%2F%2Fadil.ncsa%2Ftargeted%2FSIA
This is the SIA service to the ADIL (wrapped in an OAI envelope--just look 
for the VOResource element; within that, find the SimpleImageAccess 
element for SIA-specific info).

> And, how about extending it to work also with SSA? The number of additional 
> elements should be marginal.

I think at this stage, you should approach this by defining a "new" set of 
metadata that will be very similiar to SIA.  Reuse the same names where 
the concepts are the same.  I would defer linking the two sets of metadata 
in a formal way to a time when the two services are formally connected at 
the protocol level (e.g. "SDA").  In practical terms, this would mean 
creating an SSA extension schema with a different namespace as SIA's; 
although much of the definition can be cut-and-pasted in from SIA.  

> The SIA query mode (and presumably SSA query mode) returns a VOTable that 
> requires special client software to parse it. The question is whether we can 
> avoid this in future by re-using things like the VOResource in the SIA/SSA 
> query mode context. It seems, however, that the given SIA schema is 
> weaving in what I would call registry-type components (VOResource, 
> VODataService) PLUS SIA specific elements. The presence of the Schema 
> suggests that SIA servers and clients need to support all of it(?)

As you may now understand, VOResource and its SIA extension was not 
designed to encode SIA query responses.  They are about describing the 
service itself and helping applications to use it intelligently.  (Thus, 
your assessment of the "weaving in" is absolutely correct!)  Since, an SIA 
query response is essentially a table, using VOTable seems a good choice 
for this.

I hope this helps.  Let me know if you have more questions.

cheers,
Ray


From owner-dal@eso.org  Thu Apr  1 17:21:25 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31FL3Ta016796
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 1 Apr 2004 17:21:03 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i31FL3YF016794
	for dal-outgoing; Thu, 1 Apr 2004 17:21:03 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i31FKuTa016763;
	Thu, 1 Apr 2004 17:20:56 +0200 (MEST)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i31FKs3R013633;
	Thu, 1 Apr 2004 17:20:55 +0200 (CEST)
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head.cfa.harvard.edu (d/w) with ESMTP id i31FKr3P020622;
	Thu, 1 Apr 2004 10:20:53 -0500 (EST)
From: Arnold Rots <arots@head.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id i31FKqLc016068;
	Thu, 1 Apr 2004 10:20:52 -0500 (EST)
Message-Id: <200404011520.i31FKqLc016068@xebec.cfa.harvard.edu>
Subject: Re: New UCD1+ for SIA protocol
In-Reply-To: <200403241946.i2OJkEu1003422@xebec.cfa.harvard.edu>
To: dal@ivoa.net, ucd@ivoa.net
Date: Thu, 1 Apr 2004 10:20:52 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Arnold Rots <arots@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

I was asked to write something about the SCORE parameter for SIAP:

SCORE
This parameter is intended to aid the user in selecting an image in
cases where a SIAP query would return multiple images.  This is
especially intended for non-expert users and for users who have no
need, for their present purposes, to check through the metadata
provided in other parameters.
The criteria for determining the SCORE are entirely up to the service
provider, since different considerations come into play for different
archives.  Some hints are provided below.  We implicitly trust the
providers to choose the best algorithm for the majority of the users,
based on the fact that they know their data properties better than
anybody else.

Output
SCORE is a floating point value that ranks returned images according
to their relevance for the query as perceived by the server.  This is
meant to aid the client (especially the non-specialist client) in
choosing from a list of images in case more than one image satisfies
the query criteria.  The scale is always relative and only meaningful
in the context of the result in which it is provided.  The highest
number represents the "best" image available that satisfies the
query. There is no specified range.  It may measure things like
exposure time, image quality, proximity to the specified position,
resolution, etc.

Input
SCORE is a string and may assume two values:
SCORE=TOP
If multiple images satisfy the query criteria, only the one with the
highest value of SCORE (in output) is returned.
SCORE=ALL
(default) All images satisfying the query criteria are returned.


This issue is important for archives of pointed observations where
dozens of images may be available satisfying a single query.  Expert
users may want to see the metadata on all of them and choose, but
less sophisticated users and more general services (the issue came up
in some of our prototypes/demos as a real problem!) are more likely
get annoyed and say: just get me what you think is the best one.  And
that's what this is about.

Note that SCORE is not necessarily a measure of data quality: a 1000 s
exposure of high-quality data may still score lower than a 100000 s
exposure of somewhat poorer quality.  Nor does it say anything about
how well each image satisfies the query: all returned images are
expected to match the query's criteria.

The question really is: among all these matches, how well do we think
the user will like them, or how well will they fit the user's purposes?
I would like to emphasize two things:
1. The scoring scale should be relative and only have meaning within a
particular response list.  I.e., you cannot necessarily compare the
scores that come from two different queries and deduce any meaningful
conclusion.  The scoring may not even be linear.
2. The user is free to like or to dislike, to trust or to distrust the
scores that are returned.  If the user does not like the scores, (s)he
should look at the actual metadata returned with each image in the
response.


Designing a scoring algorithm takes some thought and will be very
mission/observatory specific.  To illustrate this let me list the
considerations that went into the Chandra archive's algorithm:
 - Exposure time; clearly, longer exposures produce higher-quality
images
 - Instrument: ACIS-I/S, HRC-I/S; this is based on the different
sensitivities and spectral responses
 - Co-allignment with requested position; Chandra's PSF quickly gets
worse off-axis
 - Image resolution; we have two canned images at different
resolutions and with different FOV.

One might consider adding other factors, such as seeing/aspect
quality.  It is likely that we will continue to fine-tune the
algorithm.

I don't think it is particularly useful to publish the algorithm or
its description.  Frankly, I suspect that those who rely on SCORE
don't really care and that those who care wnat to inspect the metadata
to make their own decision.


There is no UCD that fits SCORE, it's a context-dependent thing and,
besides, it has a different datatype on input and output.


  - Arnold

--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From owner-dal@eso.org  Mon Apr  5 02:10:38 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i350AF52023306
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 5 Apr 2004 02:10:15 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i350AFRf023305
	for dal-outgoing; Mon, 5 Apr 2004 02:10:15 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i350AB52023286;
	Mon, 5 Apr 2004 02:10:11 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i350A83R011511;
	Mon, 5 Apr 2004 02:10:09 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i3509sHI001665;
	Sun, 4 Apr 2004 18:09:55 -0600
Date: Sun, 4 Apr 2004 18:09:52 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: dm@ivoa.net, <dal@ivoa.net>
Subject: Re: UTYPEs in VOTABLE for data models
In-Reply-To: <406D5489.2070904@eso.org>
Message-ID: <Pine.LNX.4.44.0404041723550.1534-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi All -

I am still trying to get caught up on the flurry of email from last week
while I was travelling.  My apologies if I haven't read all the email yet
and and if I duplicate anything which has already been said.

Anyway, on this issue of UCD and UTYPE being orthogonal, what I meant was
that each programmatic interface and interface element (service interface,
data model, etc.) has a unique UTYPE assigned to identify it, whereas UCDs
relate similar elements of different interfaces.

For example,

    UTYPE |	       UCD
    ------+--------------------------
     a.1  |  x
     a.2  |     x
     b.1  |     x
     c.1  |        x
     c.2  |     x   
     d.1  |           x

Here, the interfaces are A, B, C, etc.  The interface elements are a.1,
a.2, b.1, etc.  Every interface or interface element has a unique UTYPE.
Elements a.2, b.1, and c.2 share the same UCD, meaning that they are similar
quantities from different interfaces.

An example of this is the original use case for which UCDs were invented:
associating similar fields of catalogs from different sources.  In this
case each survey defined a specific interface (data model in this case) for
their catalog.  The interfaces were all different, hence it was difficult
to relate different catalogs.  UCDs were invented to make it easier to
relate similar fields of such catalogs.  Fields from two catalogs share
the same UCD if they are physically similar astrophysical quantities.
In this old use case, the defacto UTYPE values are the field names or
indices of the each specific catalog, e.g,. USNO.1, USNO.2, etc.

VO interfaces are similar, except that we attempt to define standard
interfaces for data access, standard data models, and so forth.  These are
really no different than the old data provider-specific interfaces,
except that we try to define a standard.  Instead of merely trying to
derive some order from chaos after the fact, we ask data providers to
implement standard interfaces which mediate (translate) external data into
some standard data model at access time.  This makes it much easier for
data analysis software to use data from multiple sources, and encourages
data providers to produce data in a form which makes rigorous automated
processing feasible.  Ultimately it makes things easier for data providers
too, by providing them with carefully designed, standard models to follow.

UCDs define a standard language for astrophysical quantities, providing
a simple tool for semantic inference and allowing data from different
sources to be compared in a semi-automated fashion (and encouraging
new data as well as standard interfaces to conform to this language).
Standard interfaces, including standard data models (like WCS, a uniform
model for physically characterizing data, etc.,) attack the problem
directly, relying upon direct mediation to map data to and from the
standard models.  The UTYPE tags merely provide a simple, direct means
to identify the elements of pre-defined standard interfaces and data models.

None of this has anything to do with mandating how code is written, and
in any case interfaces are best defined in an implementation-independent
fashion.  This is key however to be able to write code to reliably process
multiwavelength data from multiple heterogeneous sources.

	- Doug


From owner-votable@eso.org  Sun Apr 11 02:08:22 2004
Return-Path: <owner-votable@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3B07bq4029479
	for <votable-outgoing@mercury.hq.eso.org>; Sun, 11 Apr 2004 02:07:37 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3B07abm029477
	for votable-outgoing; Sun, 11 Apr 2004 02:07:36 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-votable@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3B07Xq4029460;
	Sun, 11 Apr 2004 02:07:33 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3B07UTY019764;
	Sun, 11 Apr 2004 02:07:31 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i3B07MHI007227;
	Sat, 10 Apr 2004 18:07:23 -0600
Date: Sat, 10 Apr 2004 18:07:19 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: VOTable@ivoa.net, <dal@ivoa.net>
Subject: Re: Votable/FITS fits all
In-Reply-To: <4077ED44.7030000@dial.pipex.com>
Message-ID: <Pine.LNX.4.44.0404101754310.1534-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-votable@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> NB I don't advocate stopping development effort on VOTable just now. 
> However I agree with Tony that we ought to note in the standards doc 
> that the VOTable format is not meant to be a one-size-fits-all for the 
> future.  I want to avoid seeing a whole lot of VO effort disappear into 
> trying to shoehorn all astronomical formats into VOTable, and building 
> tools, stylesheets, parsers etc to handle this VO-specific format, when 
> this effort would be better spent creating things astronomers will find 
> useful.

VOTable is actually two things: a general table mechanism (a resource of
type table) and a general XML-formatted container capable of containing
an abitrary collection of "resources" (stuctured elements expressed in
XML) of different types.  We need both things.  To describe arbitrary
datasets we need things which haven't been defined yet, to fit into the
non-table resource elements.  For stuff which is natually tabular data,
there are advantages to using a standard table format.  Of course it is
wrong to try to stuff everything into the "table" data model, but it is
a mistake to think of VOTable as only a table mechanism.

Within VO we probably have at least two classes of data: stuff which is
internal to the framework, which is probably most natually expressed in
"native" XML, and data-centric stuff, which should ideally be expressed
in a largely framework and technology independent data model, with a
clean separation between data model and representation.  For the latter,
the framework can deliver the data, but data-centric (and framework and
technology independent) code will understand it.

	- Doug

From owner-dal@eso.org  Mon Apr 12 10:42:46 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3C8gFjV002619
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 12 Apr 2004 10:42:15 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3C8gFFS002618
	for dal-outgoing; Mon, 12 Apr 2004 10:42:15 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3C8gAjV002595;
	Mon, 12 Apr 2004 10:42:10 +0200 (MEST)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3C8g8Xe010417;
	Mon, 12 Apr 2004 10:42:09 +0200 (CEST)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3C8g8u3012642;
	Mon, 12 Apr 2004 10:42:08 +0200 (MET DST)
Received: from isou53 (isou53 [193.147.153.35])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with SMTP id i3C8fxu3027564;
	Mon, 12 Apr 2004 10:41:59 +0200 (MEST)
Date: Mon, 12 Apr 2004 10:41:59 +0200
From: posuna@iso.vilspa.esa.es
To: dal@ivoa.net, dm@ivoa.net
Cc: po@iso.vilspa.esa.es, js@iso.vilspa.esa.es, Christophe.Arviset@esa.int
Subject: A note on a possible extension to SIAP
Message-Id: <20040412104159.414918f1.posuna@iso.vilspa.esa.es>
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.9; sparc-sun-solaris2.8)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart_Mon__12_Apr_2004_10:41:59_+0200_005aafd8"
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: posuna@iso.vilspa.esa.es
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

This is a multi-part message in MIME format.

--Multipart_Mon__12_Apr_2004_10:41:59_+0200_005aafd8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


Dear all,


 at the last AVO demo in garching, and in view of the need to include
 the XMM-Newton energy bands in the demonstration, we gave some ideas on
 how to allow structurized SIAP results.

 We believe that through simple modifications on the SIAP and VOTable it
 would be possible to easily show some structure in the SIAP results,
 and would like you to have a look at our note.

 We are aware of the CDS efforts in this direction, and we have had
 conversations with them. F. Bonnarel et al. will post their proposal
 soon to this list as well.


 In order to be able to include one drawing and a couple of colors to
 make things as clear as possible, we have created a PDF document with
 our notes.


 Please let us know your comments.

 Regards,

 Pedro Osuna & Jesus Salgado
-- 

Pedro Osuna Alcalaya

Software Engineer
VILSPA Archive Development Team				
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314  				

European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727 
E-28080 Villafranca del Castillo
MADRID - SPAIN


--Multipart_Mon__12_Apr_2004_10:41:59_+0200_005aafd8
Content-Type: application/octet-stream;
 name="A NOTE ON A POSSIBLE EXTENSION TO SIAP.pdf"
Content-Disposition: attachment;
 filename="A NOTE ON A POSSIBLE EXTENSION TO SIAP.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjIgDSXi48/TDQogDTEwIDAgb2JqDTw8DS9MZW5ndGggMTEgMCBSDS9GaWx0ZXIgL0Zs
YXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJrVfbctpIEP0C/0M/Ols2O7pL++bYuJat2LgMceXBL4M0
gGKhYaVhCX+/3XMRyECySW35wYMYes6c7j599HF6kTFIWDaIAKZ3Fwzor1nAxe/3DDwfH84vrtmA
+YzWOXTLLVzewON4OoTxI9zA03gyGX38NIThl+nwcTLCh9MxTEY3T/R/9Hj76fPdEB7Gz0P4ANOv
eNC1F5hDAeN7fhSa+Cb0ZPr8+Xb6+Xk40LuTGLcyvZnpbZcmyrX+4trzB4kJRagz82F+gWHjNNP7
r7s1Bn8SRSNh3G5qDrwu4C/RblqY8GrBC3kFL6NPk6cbYDHcrBvwGQsNCD+I3qGgqKk+bNshMrt6
kDxHJDvcSQyEA99sujxmxT6a/kbHsIhlln/fLDHOdClgJQtRVWW9ADkHhQ+2S1kJaFWzydWmEfSY
1ztYN/KryBXIBjh+KWu5KnNegZzpx2ULHBblgteqzE/gIwhxEB5B2MrmDY8s8yWFmAkCskROK1HA
bKcB3XHF4cHAtDwmlkWKGqSRi5qmlkoMsmjkZg2vl5QfiWGa9vXDAP6UW/GPaK5gKzq6k34lscjz
O5ierdSZqEr8IeLhCnhREMz5ps5VKWtelQqRSg1WF2xZI02FaOjhTACfIaG4LMp2XfEdvPp+MHH8
FmfISpLUogiizDMoxhu13ij8eWj4Xm2QNsHbko7i7ZuBl8tNVdC5jsdtqZa4G5+vK51PzHk5x+wR
+paQneooFoRdxdCJGgGvGsGLHYhvZauIBCwLJXNZtboRlMSVKXYvCeg6h9Xeq95ru+GoXo+YyFx+
zQojjAy/ensQUJ905eAx36EOoyg1+3UiVLPTGGHF3yiRiL6FvBK8gbasc6HTh7WxQ+oWZV3j97pM
tmVVgSlTw6OBb87ta1AncWGSmJPbtciJaiSMr4j9eSNXIDcNfHl4MDxF6Z4nDOKH8SFZ13pTODjY
waLQnRMEkU3Mo9gqWQNv8mWJdVpQz9BtNfoFPWrlSsBC1KLBrrUpiH1ziR7fUZA4ws0Sw5d10dUL
lhhRJerCZpqFP8i02bDn6mA0nNCtA707UxKeZwF6XWPsCY28nyIziMMuWJb0yCQSZ7wVcHv3gEpy
K7FK1mqD9O0l6fUD9lWteEmNhKzMZVXJLXWGuXtkxNzdjaZfb04pEof2D1PKbF/K/SllvjmWey/t
V6C7r71pcCaeF/ZKjqUWE67jOIktp7NWNP/onJtfxUfw+mlO0qOO+EU8UbivwNDmZPhtLVvUy9b8
JPIH38XCBu/r+hexJCxwWMySzAU2cO6QhOy7SLC9/x9SfN/o4OWTLGvSXvPr7FzNRMlROliUdkMl
8JzteKrQvKxoxus5CaYkoREVV4I0HToVa4VSWjetV2hxB05lJYwSBPqw81zgoYNTZfx+8mR7IQ0D
f+9V5qWoipbGKx1ucea8pmGnlTuXJLLfBnCPNsVK7pXb37Uz3RKNT7lYKqilOqMxLHFzJ4icRcNz
Wpq5enqgD8JpcE+YYDyHl1JsUSXuxy+wFHVunIrXn04s7qopCD3baGIuG7VEIZmTt6oRt6n0KzoA
T2ot1EKsUXOdbfGO5w8LY8ebZ5YYXdrL47zmNOVs5j5KbCUd1hqXXNQKk2+/LoRCVyfRKNGnWbfZ
GLSTSUsDq7WDyHe63Ai0iPnGFJIefapcaS/k/nOSS33zFR6CdgIrrSXJsUlbob1BLlaIzhqLIP2B
sbAbflhmnt9Z4jCLrB8daStLVaGZN2ZYT1NtlPEBjj9yBWh0weY46Q2UkLke84LQ1s1pH0g2EQcX
2cHObhfa3bkcJ8cqxpzdNZFtLEtNfHaAxP1qOcOI12GPw9hif+bUL8YKaWdZlW/6Giu+NiR1Vib7
OR+TZp2PYUHUG72d4uwnrStUouvOMmj9RZYd8eR5gWvfMIytDzwY28SyOswlRtc2ySaFfLxJr+/3
Wvg/3KvrQj+J7cTQnPG63ZqXAjTj+D6Bpzbi740wTloXmU28n/QNk65Wz0lHbJYYtnOTNKrLXAxg
VJucOIboytYqsHdGOXTGB5XIVr8hR+f6btzxsuTICyrd+GUAJMNbjNu9P9m478WzCx4lgRWDTgqg
xCYjtcFXp2pH/YaqU0vzDNnoJElzpM9sSCSFUSPbiK4cddZOKlKcOMawJ92LHM/fKMfcvKkh+zg2
TKBcNnj6WtZm5qFdNjJv6v3Q21m7FqbfU6EwPe634fTiX3SZe9oNZW5kc3RyZWFtDWVuZG9iag0x
MSAwIG9iag0xNjY5DWVuZG9iag00IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFIN
L1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjAgNiAwIFIgDS9GMSA4IDAgUiANPj4NL1Byb2NTZXQg
MiAwIFINPj4NL0NvbnRlbnRzIDEwIDAgUg0+Pg1lbmRvYmoNMTUgMCBvYmoNPDwNL0xlbmd0aCAx
NiAwIFINL0ZpbHRlciAvRmxhdGVEZWNvZGUgDT4+DXN0cmVhbQ0KSIkrVOA1MjLQM1UwAEJdYwtD
PXNTBUsDBXMjA4XkXAVe/cxcQwWXfF4AngUILg1lbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDTQ2
DWVuZG9iag0xMyAwIG9iag08PA0vVHlwZSAvWE9iamVjdA0vU3VidHlwZSAvSW1hZ2UNL05hbWUg
L2ltMQ0vRmlsdGVyIC9EQ1REZWNvZGUgDS9XaWR0aCAzNjMNL0hlaWdodCA2MjkNL0JpdHNQZXJD
b21wb25lbnQgOA0vQ29sb3JTcGFjZSAvRGV2aWNlR3JheQ0vTGVuZ3RoIDE0IDAgUg0+Pg1zdHJl
YW0NCv/Y/+4ADkFkb2JlAGSAAAAAAP/bAEMACQYGBgcGCAgICQ0JCgoNEQ4NDQwSGhkUEBQYGR8g
Hh4eHiEiKCgkIyQlICcrKyssLjMzMzItMzMzMzMzMzMzM//AAAsIAnUBawEBEQD/xADSAAABBQEB
AQEBAQAAAAAAAAADAAECBAUGBwgJCgsQAAEEAQMCBAIFBgYIBwMNYQEAAhEDBCESMQVBUWETInGB
MgYUkaGxQiMkFVJiMzTBcoJDByWSCFPR8GNzNRbhovGygyZEk1RkRcKjdDYXGNJV4mXys4TD03Xj
80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3KDhIWGh4iJiouMjY6PgJ
GSk5SVlpeYmZqbnJ2en5ChoqOkpaanqKmqq6ytrq+v/dAAQABP/aAAgBAQAAPwDv/qr9VPq51DoW
Nl5nTqMjIuda6y2xsucfUdqStX/WN9UP+cjF/vAl/rG+qH/ORi/3gS/1jfVD/nIxf7wL/9D1T/WN
9UP+cjF/vAl/rG+qH/ORi/3gS/1jfVD/AJyMX+8CX+sb6of85GL/AHgX/9H1T/WN9UP+cjF/vAl/
rG+qH/ORi/3gS/1jfVD/AJyMX+8CX+sb6of85GL/AHgX/9L1T/WN9UP+cjF/vAl/rG+qH/ORi/3g
T/UcuP1Q6KSST9lrEk+S3F//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJYFX146FfU
y2lnUbq3gOZZV03Mc1wPBBFRBB7EL//Q9V/15dI/4j9U/wCuXm/9IUv9eXSP+I/VP+uXm/8ASFL/
AF5dI/4j9U/65eb/ANIUv9eXSP8AiP1T/rl5v/SFf//R9V/15dI/4j9U/wCuXm/9IUv9eXSP+I/V
P+uXm/8ASFL/AF5dI/4j9U/65eb/ANIUv9eXSP8AiP1T/rl5v/SFf//S9V/15dI/4j9U/wCuXm/9
IUP/AF9fV3bO7M+lsj7DlTvmNkelO/vt+lHuiNVP6j/8pfA/37/0Mct1f//T9xSSSX//1PcUkkl/
/9X3FJJJf//W9U+o3/KQ6L/yVr/It1JJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cV
hfUX/lF/V/8A5IY/+8BbqS//1PcUkkl//9X3FJJcN/wr/wC8n/6Mr//W7T6ufV/pR+r+BkZPUuo4
5ybXVtbXnXsZvdY4ABrXQJWjb0DoFOdXg2dY6o3JsDS2s9QyZO7dH5/fY6PgVkdXb0XpuTt+39Ss
pYAbXnq17XD9Ia3bW7j9EtP0i0E6NLjIF+zA+qVdmRW/r3U2uxxabJ6jk6CoEv13a7Y90ccHVf/X
7yzC+qNVlldnXuptcx1rTPUMmJqa42Qd0HaGndHEQdVfyPqt0bGxX5V/VuqVUMbvdY/qWQGgeM71
To6b9VsiuyxnW+qAVOra8P6hktc02O2slpcDDjoDEHslkdM+q2O3db1zqjRutaY6hkmPSdteTDtA
06EnQL//0PQB0r6rnKsxv251L1K9wcD1HIiWjc4B2+CQNSAZA5VvF+qnSsvGqyKOp9XfVa0OY79o
ZIkHg6vRf9ZWB/zo9W/66GR/zdL/AFlYH/Oj1b/roZH/ADdf/9H1D/WVgf8AOj1b/roZH/N0v9ZW
B/zo9W/66GR/zdT+ojdv1N6I2SYxaxJMnhby/9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W
9xSSXFfU365/U/G+qXRKMjrvTqbasKhj67MqoOY4MEggukEL/9f1X/X39R/+5h6X/wBVdX/Nkv8A
X39R/wDuYel/9VdX/Nkv9ff1H/7mHpf/AFV1f82S/wBff1H/AO5h6X/1V1f82X//0PVf9ff1H/7m
Hpf/AFV1f82S/wBff1H/AO5h6X/1V1f82S/19/Uf/uYel/8AVXV/zZL/AF9/Uf8A7mHpf/VXV/zZ
f//R9V/19/Uf/uYel/8AVXV/zZcf/ro+rP2jf+18Lb/rh+0bvtFcel6W3fz9GdJ4nRa3Q/qzi9S+
pztj7asrKqsayz1rNtb22kscGh0NLXNaZAB0UukfVrqGRi09TduwM5+cMs1Zhfc5lbK31srLi+eH
F3OhcV//0vQMj6kdUsweo49fUaQ7qlZblvfQTDjbZYdg36D9IRBmInmVLr31UyXdBzW02etcyrq7
662t1sdl+o5rRryN0efkl1D6iW5mTkvGW2mu37Y5rWCyN2RW9klhs2SN5JIaC7vyVe6x0zq1nQsS
slmdk4eTj3urpb6YvbVYHbQHOIDoEiTG4dgv/9Pt/rJjdb61YOo4PT7MduLVWwtyWj1Lz9ppsIa0
O4YKjzzuIb4qGF9W+s9Vx8mnLsditGTmPdTYyxtV7Mh+9riG2NLtokFjjGsESFcu+o+ZU/Osxc6w
se7Muqo9S0Nc+9r/AGFvqentDnk6NB0EnmerwmXMw8dl0eo2toft43Aawv/U9xSSSX//1fVPqN/y
kOi/8la/yLdSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FcN9XvrXiYH1I6IzGa3K
yq8fAoNLnGtodaWMBLy0iAXaxK3cfr3URl4OPm4VNP2y51THUZHqAbanvJPsb+7EeazLf7YmDVkV
VOZRV+jpstF+Q1j4sP5gIh0DUyW+Ak6L/9P0XL631bqlHTP2UbMe7JpyrjXWa/o1Oa2dz2OEy4Q3
aJJ1c0AzH6t/WjKzuq4lV9rrKs/puNkiWtDachzNxraQJ9zPfDiSI5gwNHJ+tuBh5nWKMpvpN6bX
Q/cHS642h0Na3u6RAHckKkPrpl19QxsLL6czFuuvpoFb7/0k2Na4uaNgDmtkiQ46iIA1H//U9Izv
rTdkdH6bZiNfjZHVMbHvp2lpc11j6xslzSOH6uIMATtPCz6fr1k9NbZg9R9J2bTkZFZfl3Mqa5tY
rcPe1kOcfUAb7WyBJDV2eFlVZmHj5VX8XfWyxuoOjhI1BIPPYkeBXGf8K/8AvJ/+jK//1e8+r31j
r6f9V6K2Yt1t7CGVhzHMqtstv2MaLSNvLxMSQJMaImX9bOvYOZdgPxsfMyW1tfOMLIqPqVtIcCPd
7bJbtMu2xAJChV9eOqWOyq2YTLLKvtQYCH1l3osoIJa8Bwn1T7TroACeUTB+t3WM7qdnS6aKGXiy
xrbbmW1gtZWx5ljgHAk2NAHgCZOgP//W9Gv+uWTiNdk5ePUzGZb6dgqfvcA3BdkvIOgPAa3x1KNl
dd+sfTunv6jmYFFuOcd9xZj2HdQ4NlrXlwhwJ0LgBHO2JIr9R+t/UekX24+bj0XWUt9V5oc4AsOP
kWgazDt1BHfQg+SJR9aOqV9Wxun5lOPutfitL6S6Iurvdwe4NQHnM6cD/9f0X/XnkGno9gorP27d
v1PsjMoo0+VpPxCNlfWHq9vWqum9OrxtznZQL7y6IpFP7vcm0/cqGV9fcqp5x/sopycduQcn9Hdd
WDU/boa2Ehrudzh7RGhKvs+uO/EvyvTqbWzK9FhseWgt+zC6SSJHOumg7L//0PQqvrl1IVVWW4Yd
VZYWsu2WVNsAxrrTtbYA7Q1gbiIIdpwiYXWMyv60U0Xv3V5OPUzIDXk1V5TmuexrAfojYx27xJbp
JV76jf8AKQ6L/wAla/yLdX//0fcUkkl//9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJcZ03ob+uf
2tvq/hsdU0ijAuAyK/Urd6RY/a5siQYg6r//1vUcD6qY4xxXm0YlRrtNtJ6XXZjbHFpaTLXzJBIm
eNFZH1T6ABQG4xa2llVYY2ywMc2oywPaHQ/b23Aqpm9E+p/TaK25dowqy54rNuXZXG4e9rSXiA6J
c0aE6kTqrPTOkfVmlow8AVk4NtVpYy5zn1PFQYwn3Ej9GAADy3yX/9f0Tq/1Is6h1rqGdPT7WZtN
dZGbies6rY1wlh3tiZ1+C1cP6q9LxziWP9W+7HFR3vts2vsrrDA9zN2wugcx+RRx/qf9Xsak01Y7
wz066m7rrXGttbtzQwlxLIOo2xrHgEzfqb9XmMc1lFrC99j32NyLhY82BofLw/cQ7a2QTBIB5X//
0PbqqqqamVVMbXXW0NYxggNA0AA7ALif+Ff/AHk//RlaX1a6dR1L6lYmLc57GuLnNfWYcx7Li5rg
fFrgCPgtDH6Fe91p6pnP6mx9fpimxjG1RIMlgEF0ganjsBrP/9H1v/Wx0kZOPZXRXXTVVkVuoDBs
s9Ys3Fw7/Q+aL/rd6D6Bo/Z+P6brPULTWNXxt3fGNJ8NOFWf9Uujmy8tpYK8m71L6yxu1zfs5p2j
T2jae2upHBhPhfV/IpfW3L6lfn41VTqmUWhga5pEfpIA9QxprprJBOq//9L1m36q9Gd9mZVjVUVV
XuusrYwbbt1D6iHeI2v/AAjhW8novSMt27Iw6bj7NXsB+gHBv97udHhJhBb9WPq4xj629MxQx7Wt
c30mwWtIcBEcSAfiAVVyfqtUMvAyOmXDpf2RuQ3bTU0h4uLC466TLOdeV//T9Zxvqr0evFbTlUt6
g8WW3Ouymtc977HS8mAAAdNAAIAEaK1Z0LotmW7Lfg47sh0zYa27jLdpkxr7dPhoq2R9V+kWY7ce
nHqxqi97rBXW2X7qn18xoQH8+AjglW6ek9NoobSzHrDQ+t/0Rq+sNDXHzAa0T5Bf/9T1T6jf8pDo
v/JWv8i3Ukl//9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJJJf//R9xXm+Pf16n+150KCPRsHS6qm
4djq73tfZW1zdxIAkEiQQtin7f067puQcbqtNP2p4ya7rn5TvTFD9phjrDG8jTxg9pWTbk/XP18N
32bLeX0YjqB6lzC1xPv3htb65/e9UiBxrqv/0u1rszMnG6aOo1dSAopzK7300W+t6rnNNYnbJYWy
e7CQ0P4AVXprev4uDj9SfRfQ2npNPTXsNbmvaW43qG0iARtsPp+Wp81Bh656WLVi2dTxTkdMdk2/
aLvXdeWuqn02te5zfpawWmHe0EjS/wBJzOtYuczIya+oHCGZeNuzItir7PVt0cwPI9TdEt5nUgSv
/9PsG5fWKK+nu6i7qNWQbOj10x6npbXuqFotI9u4uLw7eZ4jnVdC+19Z6tjUZefmtrb0v1v0ORYy
X/abWyYInQAa+C6r6qZ+Tn9AxcjIs9ewmxnqxHqtZY5rXwNPcAHaaa6aLnf+Ff8A3k//AEZX/9Tq
H497fqAy7LzGuwH34zXY72NDWD7bWHEv5IiZnTVV/rHZ0Zjcmroz8WzpIs6b67PVAwxacoaFwkNl
n047RI4WjWOjMw8MhnS8fp7uoNb1E9Mu31GsVP8AT9Vwa2G+ptBB04nQldL9Wq/q+z7d+xLg/G9V
s10Gcet+0T6cDbqCC4NMT4GV/9X3FJJJf//W9xSSSX//1/cUlhfUb/lIdF/5K1/kW6v/0PcUkkl/
/9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJch0d/RG/2uOgjrNTb8R+Jht9N1TrdzztDAGNBJO6I
gcr/1fTum9T+qHS6HNwKDiG25tbqK8W1tznljnCatm+NrXEGIgHXRWf9eP1f9Jlovscx87Syi0n+
N9KIDJkv9oHJPEq5idb6ZmY+XkVWlteI5zLzax1fplrQ4yHgEQCCVSf9a/q9Zj3eu+1lXpbyL8e1
vqsJDfYHMG+S4CGydRpqF//W9J6b1D6i9LsP7OxW41zzZU5uPh2C0+mGuc0tFe6AHtOvitGv619A
ssY1uVLbI23FjxSZr9T+NjZOzWNyg/6xfV7MqY2z1Hg2UOZXZjWhznOdurc1pZJEtkOAgRyIUcro
/wBT78005WBh2XYmMHkW1NIrpc5/ciIkO0+a/9f1Sj63/VgYuO+jI/V3VMe11dNmyutxLWlxDYY0
lpA3RwewWH/wr/7yf/oyrH1b+sHRsL6rYtV1td9tb2ssx63NdY31cgMaS0mQJe0z4LWz/rN0rEzX
4N1Vjq6nUsvuDW+jQ60wwPJIidOAYkTEhf/Q9f6d1Xpebl5mJg7bRjNrNtlW017nz7ZB1cAAT5EL
Ra1rWhrQGgcAJ0l//9H3FJJJf//S9xSSSX//0/VPqN/ykOi/8la/yLdSSX//1PcUkkl//9X3FJJJ
f//W9xSSSX//1/cUkkl//9D3Fef9J6BUfqL9X8vp3Tm25hHS77vRDG2WtqfW92ri0Ew3uQtS/oOf
1zqOVn5OOzAbsx6qastldxf6RtJc4NdDQfUhu14dpMwYLYv1Ly6KbML7VTZiuxQwm2gPLrfXfaSW
ucRsl0RzHDgRK//R9V6Z9Xrel9J6lj02VX35j7bRvYRSHuYGtbtJcdgDRIk9/gsbE+rvU+p2tf1O
rLquYysuyM22t53tuqsLaq6nbGsPp6uIDuNOVcyfq31ev6wszun5TaRccuy2yysODDYyhjW7dwJ/
ii6R3GunMKP7X2HW/ZZkevj/AGf7O0Wsm1jPQ9IhjyYYDq47WgkkySJC/9L0HC+o+T03Jw8jFy63
Prup9Tcx+01Ma8E7fUPvcXanjQQ0RrY6t0HqXUvrQdzQ3pN+HSzKduE2+nZY70o5h28bjwWgt76V
+nfU3L/ZL8ay/wCxjNoOPnVbA8vrD3/QcHQ0lryCYdpEAESq3/Cv/vJ/+jK//9Pu8PolnV/7X1GL
jV0m6yxj/wBK4ta8V5IeQXNaSJDY4Ks4P1OvGP1jHtrp6fjZ1DWMxsa59rWXAuJul7Ww7VvA12iZ
0jY+rfSr+m9Pc3KNRy8m1+RkuonYbHHhs6w1oDR5Baq//9T3FJJJf//V9xSSSX//1vcUlhfUb/lI
dF/5K1/kW6v/1/cUkkl//9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJcV9TfqZ9T8n6pdEvyOhdO
uttwqHvssxai5ziwSSS2SSv/1PRcrov9qnDyHY+VgdBx7mxurtqx2uEiRIInVHH1V/tbkwOj9GJ9
Y0fyej+NH5nH0vLlDp+r39q+9j309M6Ha2t7a3uZTjkNe4wGmBoSdAFlZjP7WmF11vSLvqtiCw3U
0+r9jxtm636MAneWzoXBpAPdf//V7vpfT/7Wefi599n1e6b0/wCwXGjKZm4uO11ToBG4iRB3CDOq
t1dD/tVXY12TV0/oNlFEera2rHLK543GIE+aJR9Wv7WWQWinpXRLS/dtDKKDO0AmIHYEE+AI8UO3
oX9qukVG3p/QaxcwWVl1WON7D+cNNR5hf//W9V/1ifUf/uXul/8AVJV/zVcf/rX+rP2jZ+yMLb/r
h+z7fs9cel6W7Zx9HdrHE6q5h9U67076k0X0UVtpruoFdlVu66zflsa5vpuYGiQ5wnee3E6E6p9Z
PrHZd1A1VXYLqTihmJZtD2473kPuLg2wCSNum4MaCSJMj//X6u36ydeq6ZfkZ2RkdPppxsuzGura
2w3vYRsk+kJETtG1u4ayeQTqvXvrAx3V7KMq2kYmLlWRYAS7bjOc0tYKyGtD9pD3P1IIjUAXOrfW
XqH2y3Jwsl7cBpawONcAOGLkvdO5v7wqnwIjxC1Pqr1SzqVuTY/MN+ynF/RjbtaX1BxdoJkknv8A
Jf/Q9xSSSX//0fcUkkl//9L1T6jf8pDov/JWv8i3Ukl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3
FJJJf//X9xWF9Rf+UX9X/wDkhj/7wFxPUH2YX9sH6yXZFLhRkOwixz+l25QsDaQHbXtIDY4PP4LT
t+of1hyMnIx35GLTg3dYyOp+tW55vaLK3MDQ3aBI3TO5f//Q6ej+1z9ZaeljHZfgttx24DKGx7X/
AGa5tm5zhW1wkNgN9wEkyrN31I+sV/VG5dtfTXuf1XF6k+8vf61YrDA6pp9PVvt9pkeELG+sn1I+
sHTPqr1zIa6vMyOpYzXdQZjte51mUMoPa9jdskBji0jTQBTwvqzl9f6h1i9uKPdiYjce+zEswaXO
bd6kbNXFzdoIdqBMEEaL/9Hq+m/UP609Msx8ui3CvyG39SusZdY4N/WRWGgObUJ27JPtE8AayMfr
v9r7rfR/qxmsqrxup+rhdMoeQ15uqfjlrT6TQ0y088iNdF68uG/4V/8AeT/9GV//0vS/qz03C6p9
S8TDzKzbTYXFzQ5zTLbi4EFpBBBAOhUqsjofRcbD6lg1NsxOoPoqsy3XOc/a87ajLyS5u5+uogEl
WLOu9GzszqfRM0tYW2DEcx5MXNspa/nSJDiAJkwSFYozeg9bxcnAqtZk0vpLLKxI3VPBbI4lpEgO
GngV/9P2vJw8bKFYvZ6grJcASYktc0yO4hxEFD6d0zC6bjtoxK/TYPElzj4S5xJMcCToNBorSS//
1PcUkkl//9X3FJYX1G/5SHRf+Stf5Fur/9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSS
XMdJ6P8AXHpXTMPp1Gb059WJUyljrMe3cWtEAmLYlf/T9U9H68f8S+l/9U9v/SVL0frx/wAS+l/9
U9v/AElS9H68f8S+l/8AVPb/ANJUvR+vH/Evpf8A1T2/9JV//9T0fo+b9dup4RyRf0ysC/Ip2mi0
/wAVa+uf43vtlXfR+vH/ABL6X/1T2/8ASVL0frx/xL6X/wBU9v8A0lS9H68f8S+l/wDVPb/0lX//
1fVPR+vH/Evpf/VPb/0lWZ/rV+ss7/t+Fv8Atv2/+T2R60bY/jPo7fnPeE/1TqxenfV7G6o2jKyL
rA+tzKXPfp6h4rLto4GoE/egdA6HZ1b6udH6Z1LHyMSrp+Ka76bWbfVsdUawWunhoc7tyWnsv//W
9Hu+qHUsuvJxszqFdmPmX42TkFlO21z6q6mmHbiAHOqB40EhWfqz9Vsjotu+7PtyQ2hmOxhstLIb
y7bZY8AnTRsAD4roUl//1/cUkkl//9D3FJJJf//R9U+o3/KQ6L/yVr/It1JJf//S9xSSSX//0/cU
kkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJYX1M/1Ef8A8n+o/wDW3at1f//Q9xSSSX//0e9+
rn1gGH9W8Gmui11jb6ay99TxURdlNrO18bSQHzAPb4ot314vs6hnYuFjMdXVZh04+RY47bXXXuqe
6B+a0ggeJB7QUnfXTPrxc91mNV6uHh9Tvdtcdrn4lgYAO8OmfJWsr6ydSd9YndHw6seTBbbc4x/F
7+Bz4afHtC//0u6x/wC2K/JtrcMb0aW/ZW27qr3guu2zFjGOYANw2z9M+AIK6foPUn9U6Vj5j2Bj
rd8tbwIcR/MtBJf/0/cUkkl//9T3FJYX1G/5SHRf+Stf5Fur/9X3FJJJf//W9xSSSX//1/cUkkl/
/9D3FJJJf//R9xSSSX//0vcUkkl//9P1T6mf6iP/AOT/AFH/AK27VupJL//U9xSXmmH1J3UPqbT0
l3SesBvqh32nDqYda8jeCwl47tiY0WlR1DDpzBcz6sdX9JmPj49VBxq9tYoe5zCP0nILtPgv/9Xv
cjqnScmPX+pvUbYc9w34lR1eZd+f+cdT491TyD0a/IxbP9aPU2V0vse6puJVtsc5obJ9/YCB5acK
8esdMN2Pd/rP6l6mO1janDEqlgZ9ED36Bvbw7IuF9YMTAFow/qp1TGFrt7xVi1t3O8TD+V//1vTf
9ed3/cu9Z/4YZ/0kS/153f8Acu9Z/wCGGf8ASRL/AF53f9y71n/hhn/SRL/Xnd/3LvWf+GGf9JF/
/9f03/Xnd/3LvWf+GGf9JEv9ed3/AHLvWf8Ahhn/AEkS/wBed3/cu9Z/4YZ/0kS/153f9y71n/hh
n/SRf//Q9T+obt31N6I6C2cWsweRot5JJf/R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcU
kkl//9b22vJx7XvZXax7mfSa1wJbqRr4agj5FEWF9TP9RH/8n+o/9bdq3V//1/cUkkl//9D1T6j/
APKXwP8Afv8A0Mct1JJf/9H2nqGbXgYGTmWte9mPU+1zamlzyGiSAByfALmbP7YmPiixnUOlZuFk
+hXkUY7/AEy+5tlja2gbXkB25wBDiIlE/wBf1H2pmAOl5h6ico4zsP8ARBzSKvV3bi/YWlmog+Sf
pX9sLo/UcWzJFN9FVfT39QebAJFbbLGEQCfdNZK//9L0PI/ti4uJhU5OZ0vMxPtNlDMZt5qaLvVD
nAh5ftEBpLgSCNPFdB0Xq2P1jptOdQ0sZbuG1zmktLSQRLSRyOxV5Jf/0/cUlhfUb/lIdF/5K1/k
W6v/1PcUkkl//9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJJJf//R9xSVLB6Pg4GVnZWO1zbc2wWX
Fz3EFwAGgJ04/wAwrq//0vVPqZ/qI/8A5P8AUf8ArbtW6kkv/9P3FJYX1H/5S+B/v3/oY5bq/9T3
FJV+o412X0/Lxqb3Ytt1L62XM+lU5zSA4ajUHXlcT9XP7Wpxqs2jqteH6N9NVf6mLDbZYx24Wuue
d4dIBABgHVf/1fVMH6m9GwsrFy2etbk491l/r32ufZY99fpkvcdTDdAOAquP/a6+ruOaPT+0BtWO
7FLPVIbbS573OY8D6QJeefJEq+ofRq8JuMbsyz0302U2WZDy+g1Ahmwk6QCR5zrK2OldMxOlYFOF
iNLaapjc4ucSSSSSdSSSST4lf//W9xSSSX//1/VPqN/ykOi/8la/yLdSSX//0PcUkkl//9H3FJJJ
f//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSWF9TP9RH/APJ/qP8A1t2rdX//1vcUkkl//9f1T/WT
9XQXbab6w5xdtryr2tBJkw0PAGvYJf6y+gfuZX/VZkf9JEv9ZfQP3Mr/AKrMj/pIl/rL6B+5lf8A
VZkf9JF//9D1T/WX0D9zK/6rMj/pIl/rL6B+5lf9VmR/0kS/1l9A/cyv+qzI/wCkiyfqp9V+k531
dwMnJOVZdbWS9xy8gSZPhYv/0fVP9ZfQP3Mr/qsyP+kiX+svoH7mV/1WZH/SRL/WX0D9zK/6rMj/
AKSJf6y+gfuZX/VZkf8ASRf/0vVP9ZfQP3Mr/qsyP+kiX+svoH7mV/1WZH/SRa2FhYuBiUYmLWKq
KGBlbB+a0cDVHX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fVP
qZ/qI/8A5P8AUf8ArbtW6kkv/9L3FJJJf//T9xSSSX//1PcVhfUf/lKdL/0o/wC9FbqS/9X3FJJJ
f//W9xSSSX//1/cUkkl//9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSWF9TP9RH/APJ/
qP8A1t2rdX//1fcUkkl//9b3FJJJf//X9xSSWF9R/wDlKdL/ANKP+9Ff/9D3FJJJf//R9xSSSX//
0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PVPqZ/qI/8A5P8AUf8A
rbtW6kkv/9H3FJJJf//S9xSSWb0jrTOqWZzG491H2S41H1mObv7giQNCPmO/af/T9xWF9R/+Up0v
/Sj/AL0VupL/1PcUkkl//9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJJJf//R9xSSSX//0vcUkkl/
/9P3FJYX1M/1Ef8A8n+o/wDW3at1f//U9xSSSX//1fcUkkl//9b3FJJcb9VvrT0Lp/QMHDy8g030
sLLK3V2S0hx0+iv/1/VP9fH1X/4m/wDIdn/NUv8AXx9V/wDib/yHZ/zVL/Xx9V/+Jv8AyHZ/zVL/
AF8fVf8A4m/8h2f81X//0PVP9fH1X/4m/wDIdn/NUv8AXx9V/wDib/yHZ/zVL/Xx9V/+Jv8AyHZ/
zVL/AF8fVf8A4m/8h2f81X//0fVP9fH1X/4m/wDIdn/NUv8AXx9V/wDib/yHZ/zVL/Xx9V/+Jv8A
yHZ/zVL/AF8fVf8A4m/8h2f81X//0vVP9fH1X/4m/wDIdn/NUv8AXx9V/wDib/yHZ/zVL/Xx9V/+
Jv8AyHZ/zVL/AF8fVf8A4m/8h2f81X//0/VP9fH1X/4m/wDIdn/NUzvr19VWNc52cGtaJJNdkAf3
qav69/VSyttjM8OY8BzXCuyCDwfoqX+vj6r/APE3/kOz/mq//9T1T/Xx9V/+Jv8AyHZ/zVL/AF8f
Vf8A4m/8h2f81S/18fVf/ib/AMh2f81S/wBfH1X/AOJv/Idn/NV//9X1T/Xx9V/+Jv8AyHZ/zVL/
AF8fVf8A4m/8h2f81S/18fVf/ib/AMh2f81S/wBfH1X/AOJv/Idn/NV//9b1T/Xx9V/+Jv8AyHZ/
zVL/AF8fVf8A4m/8h2f81S/18fVf/ib/AMh2f81S/wBfH1X/AOJv/Idn/NV//9f1T6knd0BtgBDb
cvOsZuBBLXZNrmmD4gghbqSS/9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcU
kkl//9b3FJJZv1l/5TvV/wDknf8A7wV//9f1n6mf8o/6v/8ASuxf+hTVsJJL/9D3FJJJf//R9xSS
SX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJ
f//S9f8Aq71unr3R8bqdNbqmX74Y+JG1xb2+CX1l/wCU71f/AJJ3/wC8FB+pn/KP+r//AErsX/oU
1bC//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSS
SX//0/cUkkl//9T3FJJJf//V9xQsumy/GtqrufjPe0tbbWGlzCe43AiR5ghZf1Q6Hf0D6u4fS7rm
5D8f1AbWiA/c9zgY7aHhH+sv/Kd6v/yTv/3gr//W9Z+pn/KP+r//AErsX/oU1bCSS//X9xSSSX//
0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q
9xSSSX//0fcVwf8Abi+uuP8AVn6qX0MIdndTY/Hx2futIh7z5NB08yNIlA/tK/Xaj6xfVWjAsLWZ
3Sa2Y9jB+fWBDHj4gQfMdgQvQ1//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X
9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJeNf4Qn1JyM7Ex/rPib7HYVYoy
q+QKtxLXgeRcQ7yIOgBX/9Uv+Dz9S8iivI+tOUXVi9jsfEYDG9m4b3kdxLYHwJjgr2xJJf/W9xSS
SX//1/cUkkl//9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJ
f//X9C6R9Xej9VyetZGdQb7R1G9gcbHiGiIGh4C0v9Y/1X/4hf8AIln/ADZL/WP9V/8AiF/yJZ/z
ZL/WP9V/+IX/ACJZ/wA2X//Q9U/1j/Vf/iF/yJZ/zZRf9RPqpYxzH4Ae1wIc11lhBB7H3JV/UP6p
1VsrrwAxjAGta2ywAAcAe5S/1j/Vf/iF/wAiWf8ANl//0fVP9Y/1X/4hf8iWf82S/wBY/wBV/wDi
F/yJZ/zZL/WP9V/+IX/Iln/Nlm9Z+rnR+lWdJycGg0W/tHFZubY8y1z4I1d3X//S9xSSSX//0/cU
kkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJYX1U/42/8A
paZH/HVur//T9xSSSX//1PcUkkl//9X3FYX1s/iuk/8AS0xP97W6kv/W9xSSSX//1/cUkkl//9D3
FJJJf//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9buundC6dkO+sOfl5+diMq6
hkusNOZbVW1rQCSQ1wA05Knj4P1OycfIvp+sebZVjMNlzm9Vuito5Lv0mg80sTB+p2b632b6x51o
prNlpb1W+GMHLj79APFWOn9B+rvUhYcLrXUsj0iA8M6lkEtniRv4MaHv2X//1/UP9ZWB/wA6PVv+
uhkf83S/1lYH/Oj1b/roZH/N0v8AWVgf86PVv+uhkf8AN0v9ZWB/zo9W/wCuhkf83X//0PUP9ZWB
/wA6PVv+uhkf83S/1lYH/Oj1b/roZH/N0v8AWVgf86PVv+uhkf8AN1mdb+rOJgWdHyK8zqFzh1PE
G3IzLrGfT/dc4hf/0fcUkkl//9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W9xSSSX//1/cU
kkl//9D3FJJJf//R9xSXCWdHGZ0X65W1DIsyjZ1Kqqqu6zY8urIA9IO2OJ3aEtJ48AhfWmjqHXel
vODgZbPs/SsytzranMe91jGhtbWH3OJLZ4jQdyF//9Lvbh1DqPS8qpl3Ueovquxcj0c3EbQLGVXN
e5jSa2AlwbEE/gSt7pmZX1DqN2U3p12P6dLaxk5LDW98uJLA0iYHM8a6TqtZJf/T9xSSSX//1PcV
hfWz+K6T/wBLTE/3tbqS/9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJJJf//R9xSSSX//0vcUkkl/
/9P3FJJJf//U9xSSSX//1e9xfrAOk4f1oeyi222jIz8lh9J5pmtm6HPAgTt4mfvVjJ+vNeS60dD+
z9SGFjfa8wssDobp7GRy+Nx8BAB1IWj0z6y09W6s7GwWPdjVYwuuutrfWd1hHphoeASC0OJMRx4r
bX//1vcUkkl//9f3FJJYX1s/iuk/9LTE/wB7X//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSSSX//
1PcUkkl//9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJcv0vp7Op9K+tPT3vNbcvNzaC8CS0PaGz8p
V7B+rttWdjZudnPzbcWmymkbGMY1r9u6QBJPtHJjylf/0fXfq/0DG6HjXUU2PtFlm7dZy1oAaxg8
mMaGj4T3Wokkv//S9xSSSX//0/cVhfWz+K6T/wBLTE/3tbqS/9T3FJJJf//V9xSSSX//1vcUkkl/
/9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSSSX//1O1uozz0b65X15np47H9SDqAwe53
pnXdyOR9yWV1+zP6PTXkZWA7FZfjDN/Z+UbHNxjIeX+1pa2dod/BLp0St6l0/Bzc/wD1sPpdRdis
p24haaG5llgZSWx7Q6HOLwPzQCey3vqxSzpVmZ0EOc5mGW24xeZc6i2SJPeHh4+AC//V9xSSSX//
1vcUklhfWz+K6T/0tMT/AHtf/9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSSSX//1PcU
kkl//9X3FJJJf//W9xSSSX//1/cUlyPTOvdJ6XR9ZDlXsNlOXm5Jxw5vq2VsbuO1pInRp8lc/wBd
XT8Km6zL6dkdNLcazJYyxtRN7KwC7aa3uEiRoSDrPAJH/9D1bD+smDbmV4DsO/Ev+0nH9Oxtfsf6
JtmWucILe4J1MeKpYv1/6VlMFlWHkuL8c3sA9El7d7GhulhhxNg9rojWYRz9dMM/aBVhZd7sVtr8
htba5pbW9zCTLxMljoDZJg6cK7ifWLAy3VCkPcLct+Ix0CC5tbnzz9Ehpg8+S//R9xSSSX//0vcV
hfWz+K6T/wBLTE/3tbqS/9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl/
/9H3FJJJf//S9xSSSX//0/Q8Xpbup9E+t2HUKxflZOfRW+zhpezaJIBMa6wj3/VzqXWnUs6w2nGx
6cW2gV4lrnue6wBpcXOrbADRoIOp501vZf1XwsjMdmNvyMfIOS3JD6nNlrxUKtAWkQWiCDPKp5P1
Jpebbas/JGQ5jKmXWFjnV1i1thElkuJ2jV+46c8z/9T09v1OxXtyt91+O7JdkNvNFg/TVWWuftdL
NPpH6MESQHKxi/VXBxM+vKquvDK735DMfc30m2PYWFwG2dGkgCY7xOq2kl//1fcUklhfWz+K6T/0
tMT/AHtf/9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V
9xSSSX//1vcUlw327rWF0j6334ddLaqbeo2/aDaRbXY2slu2v0y0iQNS4d9NNXbmdbxumWZgf1je
12LpmMx3NLXX1h+xtQLids89j4r/1+46h9Y8x2XmX/bMjE6Y37Sca+qoEWWV107WiWGQXG0j94g6
kBbN/VLRi/Vf1Ms0Pz7qm2uAbNn6B79uoMbnBoMR4aLn+l/WnrTcTC+2W3G193T3WTTzU7FrdcdG
8BxJdH0fIQq/UPrF9aw51lHrOrezJsw9pDDc77Vc1jQDU/f+jFW1p26GSTyP/9D3ATAnQ94TpJL/
0fcVhfWz+K6T/wBLTE/3tbqS/9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W9xSSSX//1/cU
kkl//9D3FJJJf//R9xSSSX//0vTeiUYeRg/WWnMDTjW5+Yy4PMD0yAHSewjul0a/6mYbcnJwOoNL
Kah6rrMuyxrWEiDD3kQexHwlXsn6wfVm1l+Nd1DGLXMtbYw2j6LWkv7/AJrQd3hGqsep0fHsqwy+
ptmFSL2VuI3VVgFm/XUCJE/HzX//0/YqM7o+Hh4jGZNVdBxw+guskOqbtAcCTqPc3XzHijP6n05j
nNfk1NLbTSZcBDwzft+O3WPDVR6f1bpnUmvdhZVWSGRu9NwMTx8j28VbX//U9xSSWF9bP4rpP/S0
xP8Ae1//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3
FJJJf//V9xSXHdP6UzJo+suSyl+Vkty82urGsusFFxLdGvr3BhkmCSPnoIqsxOs9TfZkbMvKy66W
Ma/MqbjU1zdW9zGMjcdGAlxc4aAAmSv/1u+6r9RcvPtyg3IroqsbnOZtdaQX5Nb2a1lxa2DYSS36
R7CUXqJ65iu6xdn4wvbldPqxq3YFdjy6wG8/QAJAhwknTUa+FHE6Vk9Z6R0XFay/CtxukvxLDlY9
jQ2wOxXdwJ+gYjnWDoVazvqX1XqbMunLyqK6czJuybfSa4uY5+MaA1smCIIdJjXTzX//1/U/q10D
O6Xdl35eU6997Kqww222BoZuJM2En3F3HAjvJK3kkl//0PcVhfWz+K6T/wBLTE/3tbqS/9H3FJJJ
f//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0e+wuvN6
XjfWYtoustqyc7IY70nmr2M3Q54ECdvBM8eK1W/WR/63urY30c/HxWy6JFlVVhJ8x6h+5UOm/Wzq
2caRXj1OZe/HFeRstbUQ/eXBu8AvAazRwAa6VC7659Sd0nCzMbHoLrOlX9SubY50RVsljY7ndyeI
4X//0vUMf6zXXZtNBpY1tnUjhTJ+j9kN8/GRHwWPX/bEuedzscVMpFRuJqve073ubo+tjgyANN3J
005WkPrbku6ZRktor9W7DzMgNLjG6mxjAPgd+q6Wv1PTZ6hBfA3FogT3jyX/0/cUklhfWz+K6T/0
tMT/AHtf/9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJJf//T
9xSSSX//1PcUlzHSMFvUemfWjBe4sblZuZSXDloe0CfxWwzoPR25TMs4dLslhafXLBvLmt2gzHIb
oPAL/9X1b9i/VlufRiVY1VGRSWZgZVWGyGbmtkxEAuMCdFax/q70HGrsqo6fj1MsY+t7WVtAc14a
HAwOHBonxhK76u9Bvuddb07Gfa7l7q2yTETMcgaA8qTeg9Ea/Ge3Axw7Fa1lJFbf0bWmWgadjqPA
6hf/1vW8j6qfV+7HyaW4NNH2lhre6ljWuiQ7mPEAnxI1Wq1rWNDWiGtEADsE6S//1/cVhfWz+K6T
/wBLTE/3tbqS/9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJ
f//X9xSSSX//0Oyy6M/9g/XXIrzPTx2HqYdQGD3O9I67+RyPuQ+l4PT8vpmbT03E6Oc52Oz0j0rK
Bta/c0h7va3aGOAceeIgnRKz6r9VFdhyelOzsp+FdSclttUnKc8n1gS4FoOhBA3MENAgK1Z9XuuB
7oxDdnjJvtf1E2hrbqnVuDa5DvUA1a2IhpG4GQJ//9HtelfVPNffhnNwBXjnKD8nFLam0BrcexoI
ra98+5wBJcSYBMQgM6D9a6ek24TcWx1t/T+n1Os9Rjmh1D3OtY4GwE72u26aGSCQNVdOB1Pp/wBQ
vrS3Lqrxt2Plvorpbs2M9CPoCyxrZcCYaY7/AEiVQ6uzrHXM4ZdBsb+0el9QqwMYu2ba/wBCGuMx
DrJnXhu0cgr/0vQP2F1DpvWvtOF08vw6uoesyjHdW39GcP0zta5zQP0hMiR3PxxMjpvWMer6ujqH
TLHMxKcHBsq9Ss/aXgncG+6CIGu+AZjUSp5n1W+tT/fTiVvoLMgYuLeGP+xl1rnN1FrNktLfdWXF
oEN4E6N+P1PEbVRmY7m+p13HvZeHNLLA54Gg3FwOk6jiNZlf/9P3FJJJf//U9xSSSX//1fcUkkl/
/9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUlxfSOj9WzMjrr8freRg1HqWQ
PRrpoc3tOr63HX4rQZ9WOuVkln1lymE9242IP+jS/9T1D/W99Y/+5pzP+qfF/wCkSX+t76x/9zTm
f9U+L/0iULejdbpNYt+tuVWbXhjN9OINzjwBNWp0Oin/AK3vrH/3NOZ/1T4v/SJf/9X1A/V36wuB
B+tGYQdCDj4uv/ISX+t36xTP+ujMkd/s+L/0iS/1vfWP/uacz/qnxf8ApEkfq99Yjz9aMz/qnxf+
kS//1vUP9b31j/7mnM/6p8X/AKRLM630jrOLZ0e3J67k51Y6niTVbTQ1p9/iysH8V2iS/9f3FJJJ
f//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W9xSSSX//1/VPqp/x
t/8AS0yP+OrdSXlv1Kyur9T+rtfUs/K69udj5LnXsfU6gkb2gsaCbC4aQI+kPBf/0NQWfWrO6T07
I68eo151XWcV17KKCTj0DHfD62tDtTJLyJIdpGgm07qP1ydjtGXd1XHwvQzfsF1FBORda20ikWtD
CRLNRIaD3VrCzfrtd9aen0ZD8zFLXYzsr1GOdTYDQDY1gZXsDd0guc+QePBZ1+V9fcfomPltyOpX
X5XSMvItr9OTXkC2raGgNBB2kw3wmO6//9Hq+rdd+s+V9YGW4NOf9ksGL9hqrbZV6h9Rwu9QOoeB
Ea7y2G6tmZXoySwvrZ/FdJ/6WmJ/va//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJ
f//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSXKdN6lk9Iyer0X9Lz7fVz7rmPoq3Mcx0QQZV7/XX/
AM+fqn/VP/sr/9P1T/XX/wA+fqn/AFT/AOysLpmD9Uuk5tWZgfVTOxsirdssZjmRuBB/O7glbv8A
rr/58/VP+qf/AGVGz63sqrfY/pHVGsYC5xOPwBz3X//U9Ro+uNWRTXdV0nqb67Wh7HDH0c0iQeVP
/XX/AM+fqn/VP/spf66/+fP1T/qn/wBlL/XX/wA+fqn/AFT/AOyv/9X1T/XX/wA+fqn/AFT/AOyq
PU+p5PV7el49HS8+osz8e5776drGsY6SSZXVpL//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl/
/9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W9xSSSX//1/cVU6v/AKlZ3/Je3/eSgfVr/lO9
I/5J0f7wFpL/0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl/
/9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJVOr/6lZ3/ACXt/wB5K//T9f8Aq1/ynekf8k6P94C0
kkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSS
SX//1PcUkkl//9X3FJJJf//W9xVTq/8AqVnf8l7f95KB9Wv+U70j/knR/vAWkv/X9xSSSX//0PcU
kkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSS
SX//0fcUxmDGp7Ss/oTOtsw3jq767Mj1Xhpq4LBo08DUxJ+PbgG6v/qVnf8AJe3/AHkr/9L1/wCr
X/Kd6R/yTo/3gLSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//
0fcUkkl//9L3FJJJf//T9xSSSX//1PcUkkl//9X3FVOr/wCpWd/yXt/3koH1a/5TvSP+SdH+8BaS
/9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//
1vcUkkl//9f3FJJJf//Q9xSSVTq/+pWd/wAl7f8AeSv/0fX/AKtf8p3pH/JOj/eAtJJJf//S9xSS
SX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJJ
f//T9xSSSX//1PcVU6v/AKlZ3/Je3/eSgfVr/lO9I/5J0f7wFpL/1fcUkkl//9b3FJJJf//X9xSS
SX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJV
Or/6lZ3/ACXt/wB5K//Q9f8Aq1/ynekf8k6P94C0kkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3
FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xVTq/8AqVnf
8l7f95KB9Wv+U70j/knR/vAWkv/U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3
FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUklU6v/qVnf8AJe3/AHkr/9f1/wCr
X/Kd6R/yTo/3gLSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//
1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FVOr/wCpWd/yXt/3koH1a/5TvSP+SdH+8BaS
/9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//
0/cUkkl//9T3FJJJf//V9xSSVTq/+pWd/wAl7f8AeSv/1vX/AKtf8p3pH/JOj/eAtJJJf//X9xSS
SX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vQ/q3gde6r9Xekd
Sv8ArL1Flubh0ZFja68MNDrGBxAnHJiTpJK0v9b3V/8AuZ+qf8N4X/YMl/re6v8A9zP1T/hvC/7B
kv8AW91f/uZ+qf8ADeF/2DL/1/Vf9b3V/wDuZ+qf8N4X/YMl/re6v/3M/VP+G8L/ALBkv9b3V/8A
uZ+qf8N4X/YMl/re6v8A9zP1T/hvC/7Bl//Q9V/1vdX/AO5n6p/w3hf9gyX+t7q//cz9U/4bwv8A
sGS/1vdX/wC5n6p/w3hf9gyX+t7q/wD3M/VP+G8L/sGX/9H1X/W91f8A7mfqn/DeF/2DKF31Y6nd
VZVZ9ZuqOZY0tcNmHqCIP/CZbOHi1YeHj4tU+nRW2tm7mGiBP3Iy/9L3FJJJf//T9xSSSX//1PcU
kkl//9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJJJf//R9xSWH9RP+UP9Wv8ApV4f/Qlq3F//0vcU
kkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSS
SX//0/cUkkl//9T3FJCx8mjJrNlLxY1r31kj95ji1w+TgQir/9X1X6if8of6tf8ASrw/+hLVuJJL
/9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//
1vcUkkl//9f3FJJQu9b0bPRDTZtOwPJDS6NJjsv/0PWvqrj51HSC3NpGPe/LzbXVh24N9TIseIMC
RDhBgfALXWH9RP8AlD/Vr/pV4f8A0Jatxf/R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcU
kkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUklS611jA6J0rL6lnWCrH
xay97vhwB5k6Adyv/9T0b+1d1rA6v9ROiPxH7vsuLViXNPLLKmBpB+MSPIhdWkkv/9X3FJJJf//W
9xSSSX//1/cUkkl//9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3
FJJJf//X9xXjv+Ecev8A7G6YKB/co2n7QWc+rHs3fwYmPPnsue/wcndf/bnUW4+vS/RByt3As/M2
/wALnyiZ1hfQa//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W9xSS
SX//1/cUkkl//9D3FJJJf//R9xWV9Zuo5nTukOvw/TF7r8alhuaXMabbmVyWhzSY3TEj4oH2P68f
863S/wDrnW/9hSX2P68f863S/wDrnW/9hS//0vVfsf14/wCdbpf/AFzrf+wpL7H9eP8AnW6X/wBc
63/sKS+x/Xj/AJ1ul/8AXOt/7ClR639W/rT1zpWX0zO6n0uzHyqyx4/Z1sjwI/WuQdQfEL//0+7+
qX1H+sP1S6OzpfTeq9O9JrnPdZb0+wvsce7iMkAmIHHAC2vsf14/51ul/wDXOt/7Ckvsf14/51ul
/wDXOt/7Ckvsf14/51ul/wDXOt/7Cl//1PVfsf14/wCdbpf/AFzrf+wpL7H9eP8AnW6X/wBc63/s
KRPq7n9UybOr43UX0W3dPzBjizGrdW17TRVaDtc95BHqR9Lsthf/1fcUkkl//9b3FJJJf//X9xSS
SX//0PcUkkl//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJYX1z/ANRGf8n+nf8AW3Uv/9X3FJJJ
f//W9xSSSX//1/cUkkl//9D1X6vf6r/Wz/paV/8AWlircSSX/9H3FJJJf//S9xSSSX//0/cUkkl/
/9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xXP/Xo3N+rxNDG2WjN6eWNe4ta532qqASAS
B5wfgUT7Z9eP+cnpf/XRt/7BUvtn14/5yel/9dG3/sFX/9H1X7Z9eP8AnJ6X/wBdG3/sFS+2fXj/
AJyel/8AXRt/7BUvtn14/wCcnpf/AF0bf+wVL7Z9eP8AnJ6X/wBdG3/sFX//0vVftn14/wCcnpf/
AF0bf+wVL7Z9eP8AnJ6X/wBdG3/sFS+2fXj/AJyel/8AXRt/7BUvtn14/wCcnpf/AF0bf+wVf//T
9V+2fXj/AJyel/8AXRt/7BUvtn14/wCcnpf/AF0bf+wVA+qD85+b9aXZtNVGQeqM310WGxg/U8aI
cWMJ0j80a6a8ro1//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3
FJJJf//T9xSSWD9d9/7BGyN327p+3dxP2urlf//U9JyupfWLD610qu3G+22W4ma6yjCeGs9r8fa4
+o5okSR4+7TulU2zrPVurtzcrJwRhNpbVRTcazWH1NebHFphx3FzdZb7OOZyqfrD1rNwMHqDLnH9
lYVeZnCsQMoPd+74+k17w3xcwhd4x7Hsa9jg5rgCCDIIK//V9xSSSX//1vcUkkl//9f1X6vf6r/W
z/paV/8AWlircSSX/9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3
FJJJf//X9xWF9c/9RGf8n+nf9bdSj9ZbPqk7IxKetYzcq7ZY+hhx33ODZaHEBrXQJ2z8lTzsv+17
YcGm/FozNmO1+O2vEddspktEbWOgSCIPccL/0PV7etfVzBDnOBYcuoZNrWY9hd6e0ND7GhpLRDQJ
cBxHZWb+oYfT+n4X2RrLa7nU0YrKiNrg6IgifaGy7TsNFWs+uX1crqyLXZR2Y7mh7hVYZ3P2Athv
vaXe3c2ROkqbvrV0RmM3Ifbaxji+A7HtD4YAXO2lm7a2RLogTqV//9H2H9vdJ+3MwxkTa8taC1ri
zc5u4N3gbQ4t1AJkjUBF6V1AdQwa8j0zU4ufXZWTOyxjix4nvDmkT35VtJf/0vcUlh/V7/Vf62f9
LSv/AK0sVbi//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJ
f//S9xSSWD9d2Ns6CGOEtdndPBHkcupf/9P0i7ptnRfrD07I6d0u/JxG4eVS4Y7mEse+ylwn1Ht0
IYe6wKuh/WLD667Odj9Qpbk0XOcOmuxy6t1mVbbscbDBhrxJbpPdb+O3q3SepZua3p+X1JnUacYt
h1IsqfWwtLbJe0CdDLZEk8aTfzunXu6f0h9ONXVb0+6m77NSRsA2lj2t4+i17tugkgDRf//U9I6t
0vNH1hbk09Nbm4Q6Y7FfTLGtduuYS0BxAkMkgGAYiQqePhfWHEtrzPsGRk1NozMXHx3WVm+qux1T
q97nPggbXCdxIG2ZMxDpv1c6zg00dJdQ6xgzcLKOY1zfTDKKqQ4EF2/cXVED2xBBnmOm+r2FdidO
IuZ6duRffkvZM7DbY5+0nxaHAGNJGi//1fcUkkl//9b1X6vf6r/Wz/paV/8AWlircSSX/9f3FJJJ
f//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W9xWD9dnFvQQ4NLyM
7p5DREn9bq01VbL+ujMHqWLXn41uBj3YmRcW3M3Xb631gACtzhBDneeg471sT67ZdVTcrqWOx+Nk
YdmbScKHGplT3eo15L4LmNNcx+duEaL/1/TszN6u7oPSftjW42Vn5GNXkNpkek17pc0azMDaTPJk
eCBmdT+uNOfdgUjBsybsW7KxWFj9rBXaxuxx3jcXNeIPtAd5JYnXOu5rsTEx8rEOVc3JtsfZjPYK
fRNTTU6v1id+6zV26I4BkEiwfrb1POop6lXXRXhet0/Hsoc1xtc7KZS7cH7gAG+u3TaZg6iRH//Q
9b+rV9tmHk02Oc/7Jl5GOx7jJcxrzt1PMAhpPJI11Wskkv/R9xSWH9Xv9V/rZ/0tK/8ArSxVuL//
0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJYX1z/
ANRGf8n+nf8AW3Uv/9L1rqvSKsjqONnjqN/Tr6arKWup9KHse5rnAixj+7RxCr5H1R6NZg4WFfbY
Rj5Lsve5zd9z3Oc6wP01a8uO4AAR4BanUcXEzcR1N79jS9pa9pALHscHNIPiHAEfDUKp1PoeB1HM
Zk2321XModSw1PDS0OsrfuGnIdW2O3Ygyv/T9S/1sYZ3Ws6llMzPUebcxj6xa8vaxjmkbNgBFbBo
0EFoIgolf1S6XVfUaH3U41bqHnEY4ek99LWitxkF0tDGcOAO0SDC08DCpwcVmPUXEAucXPMue5zi
5zj5ucST8VYX/9T3FJJJf//V9V+r3+q/1s/6Wlf/AFpYq3Ekl//W9xSSSX//1/cUkkl//9D3FJJJ
f//R9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcVg/XZpd0ENDiwnO6eA5sSP1urUTIWN1fF
6Ni/WnpTev3s6hV9gzAyzqNdRl5soIADWNbMAxAnlUcb6qZXVeldWf8AZmOquxLqemNyGw6tv2i5
zIDhLBsLI40gdl//1u7yPq11O6uyu7CD/R6hlZNL67KnFzL3WHVljHNkS2QexkGQQs+v6v5+LXiY
V1DcezHx+jU/bAWwXNyXOe1piSZMxHIBPIVpn1U6xVj4f2fAxse3BpxK3iuyG5j6smmwuJ26ACt0
F3ul5kePVdDoza68y3LqbRZk5L7RWHbi1sBrZI0mGyY8V//X9xSSSX//0PcUlh/V7/Vf62f9LSv/
AK0sVbi//9H3FJJJf//S9xSSSX//0/cUkkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q
9xSSWD9dnsZ0EPeQ1rc7p5JPAAy6l//R9Ru+ttd+Xi4/RqG9WORTddvqua1rW1uY06nvLwjV/WN7
XZNWVhuouxmYzrGB4d/H2OYII8Ns/NLpv1kOfmUVtxHsx8lt7qLy4e4VODTLeRMyPLmDorR6vWOv
s6R6Z3vxHZXqTpDXhsR46r//0vTsP6542ViU5AxntFp6eACRp9r2x/e7tVVy/wC2J0zGyrcd7a63
UOt9QX5FVRc1lr6/ZvI3EljjGgGknULaz+pWM6n0vCpcGjJ9W6x+n8VU0THxc5vynvqqfTvrRdmX
dNdZ099GJ1QE4d5sa4v9jrBvaNW7mNJGp8DBX//T9WH1pxRidUyHUWH7Dm/YgxkF11h2BobJA9xe
AJPxMIHUOvdXo6d1Ky3Bfh34WP8AbGuBFlVzGGXM3wIcQCCCNJkTC6Fj2vY17TIcAQfIp1//1PVf
q9/qv9bP+lpX/wBaWKtxJJf/1fcUkkl//9b3FJJJf//X9xSSSX//0PcUkkl//9H3FJJJf//S9xSS
SX//0/cUkkl//9T3FYX1z/1EZ/yf6d/1t1Kv9Zfqxb1XquDnNx8DMbj491Jp6jXvbL3MO4aHUbI+
as1fVXp1jaLMmhtNzG0tfXiPeygil26sbAQIadQCPwX/1fVqPqxj4vXMXPxXurqqqyWupc9xaDa5
jvY0mGiWmQPEdgqzukfWQ/WtnVxZheiyl2KGQ/d6TrA6fDdA+CnjfUrpAxMRl9b22VVYzHii61rC
6hoDCBu/NIlp58Sjf6zeg7Cz07Ye17bv0z/07XPc9ws194LnO58SODC//9b1/qXT2ZuZjWVWsZk4
oduB1JqtBaQR2BLQQfFseKpVfV/Nx+kfVzGqtqdf0drdXg7LHNxbKhxrG54PwWfh/VTrpq6nTl5G
KwZeYOoVWUteXVXtdW5mhIBaCzUSCeJV+7p/Weo4+fg9QzsYfaqW1GjGaRtqcSLHySXbnNkN7Aju
v//X9wAAAAEAcAJ1h/V7/Vf62f8AS0r/AOtLFW4v/9D3FJJJf//R9xSSSX//0vcUkkl//9P3FJJJ
f//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSWD9d9/7BGyN327p+3dxP2urlf//Q9F6vZ1R2Vg42
Yb8nJfVe9uH0mw0teGlg3vtc9hAbuAgHUng9shuT1bJY6s5uVfdRi4T3HE9Z9b2Ovt3DfXt3HaGB
z2S72ugRuCfD6j17AxXZOYM9tb8XqZbLL7Njha30Zlu4exp2lzRpzqddhuVdV1n6oY9N+QaL8XLd
Y25z91haysgv3akiTzwv/9HsXZ/1mx2ZbLKuo2WWOxzRsqscIb1C8vEgQ2adnJEtjtCh1XM+s92V
kXVUZr8Cy/JdU39ZqeNtdIZpWxzwJFm0OAaTqe0l+3dWpwsqrKc/Hzs3q3T8S9zXt9Suuyqjdtc0
AfvgFoAkkiCrmfdl9LwvrliY+VkOZidMGTjOttc+yp767Zh7iXQDWCJJgyv/0vTcuzIzeudK6bdd
dTi2YNuS402Ordda11YDdzSHQ0OJIBE6ToEOhllXVeg11Zx6i6uzPrfadXChuha4g6ljxW0k6kjX
WV1CS//T9V+r3+q/1s/6Wlf/AFpYq3Ekl//U9xSSSX//1fcUkkl//9b3FJJJf//X9xSSSX//0PcU
kkl//9H3FJJJf//S9xSSSX//0/cVhfXP/URn/J/p3/W3UifWIfVtzcZnV8VmY5xd6FXoG6wwJcWt
a1zo4kxHE9lBn1j+rOLVQ+klofXYxrKMewuazHIDmua1ktDC6IIESv/U9Zs+tP1eLjVZkg1uBBtN
b/QP6M2Eept2H2AmJ4Wc7H+oXVc1tt/T6n5V1jK2nJxXsscSxxbo9gMFtboPGkTK0x1z6v4IzKGW
tZ9jurZdVVW4ltl7paA1oJcXOd2nWfAqDvrf0BtNlrr7AysXmyaLZYKWh1m4bZG0ETPcxzov/9X1
PM619U3ZFrsra59DnE2voeWb8YOeQ1+3aXVw8wCSIdpIKfquN9UOoZleP1LFx8m/IFTWi6rcXhws
LBMeDH88fMKjkWf2v8fGd0+3Eo+z1vdY6sYr3MrfvdVuJDCGkuY5oJiY0lauFl/V2l9NWI2qkhmR
VU2ustAbj2bbGjQQGu+/kSv/1vWavrd9X7XsazJO15rAsdVYKwbKxY0F5btBLXAgEzqBzopUfWno
l4aW3vbvNIZ6lNjN/qu2sLdzRIJ0kaeJQfq9/qv9bP8ApaV/9aWKtxf/1/cUkkl//9D3FJJJf//R
9xSSSX//0vcUkkl//9P3FJJJf//U9xSSSX//1fcUkkl//9b3FJJYP12Yx/QQx4Dmuzungg8EHLqX
/9f023op6L1XEzuk9OF2MzHux7MXGLGOaXua4PaHFrTq2HS4HgiYhUKOg/WWzrR6jW9nTDljNfYC
1tno724zGNIDh7yKi8kSAdNQdTj+17hbn1PyDbinG+ysbYzdbVX6Ho7WPJIYIl3tYCSdSRIUMf6h
W43p3UdRFWTXfVaxzaia/wBGyxoljnnV3qEuIcJgAAcr/9D0x/1NaaSBktdbax4yXW0h7b3uvFwL
mkxDXbgByA7RwIBVDI+pefRiZOPRcy6q/C6lXc1lcOL8jZtbXusgD2iNxPGpE+29n/Ux2bRdiOzt
uG5+XdVX6Y3MtyG2AkunVrTa8tbA5AJMJ3/VPqNmRTlP6oHZOPZQ6p3oDaGUstaGubu1Lja4uII8
AGr/0fTGfU0/Zc6q3ONlubVUy2z0wPe2+25zgAeCbSAOwHJUT9UeoMyDdR1Rtex2c6kOo3bftdm9
4d7xuAP0eNeZGiq4v1KynDO6dfklnSvtGK5lW0Gy5tGPS1p3z7RvZqNs+3SAUsb+12zGq/Q5xrur
+z+i9tZ2j0bA8FzS8hziWiSNogaAL//S9S+rIsHU/rSLHB7x1KoOc0QCfsOLJAkx9630kl//0/cU
kkl//9T3FJJJf//V9xSSSX//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3Fc/9e6Kcn6uu
ovYLKrczAY9jhIc05VQIPxTf8t99SP8AnDw/+Ggl/wAt99SP+cPD/wCGgv/T9Kt+pn9rum+ui3pf
Tq7rf4ut7WBz/gDqUj9S/wC12LxjnpfThcTHplrN0xPHPGqTfqZ/a6c65rel9OcaJ9UBrP0cc7vD
5pV/Ur+15Z6Xp9L6c/1t3p7WsO+OY8Y7wv/U9Lf9Sf7XzBaX9J6e0Ux6ksaNkiRPh81H/Wd/a4Ia
f2b02HuDG+1mriAQB5kEGE5+pn9rpvoT0vpw9f8Aipaz9J/R8eeycfUn+16TA6V08n1PS+g36f7v
x8uV/9X1D/lvvqR/zh4f/DQS/wCW++pH/OHh/wDDQUPqd0/C6bmfWjEwqGY2PV1RmyusQ1s4eMTA
8ySV0i//1vcUkkl//9f3FJJJf//Q9xSSSX//0fcUkkl//9L3FJJJf//T9xSSSX//1PcUkkl//9X3
FJJYX1z/ANRGf8n+nf8AW3Uv/9b3FJeTdaw+mMd9dMTrHSr8zrHUL7HdNtbjOsdZWawKBXYAQ30y
NdRHJRMf6rdf6l1jqlNuPjfaW29Idd1G9x9Wp1NNTnmuG+4uIIncNTqv/9fdH9rD6w5GN1NmS/Gq
vsqNdD8dzW1Fvrss2+m2kQHBkEuLzJ7iVpYf1O+tGB1DpPUaq8Kx+LlZtz8cObWGsurYwDdXS0Od
7SSdo7DzQ7fqB12yjqVlpovv6zW9+fU61zWC9lwfSWu2HRrfZqOw0IkLNo+pv1k6d1noTr8KnKqf
1PqGXcWulmOLKGNY522prdw2lwhoG6AIJlf/0NzF+oPWMvoGLVW3Cy683o2HhjIvL22YTqwZfUCy
SDu3Ae07hqtjC+p/1jq6k1loxjht69b1b1vVcbC0sLQ3ZsiTMk7l3qS//9H1X6vf6r/Wz/paV/8A
WlircSSX/9L3FJJJf//T9xSSSX//1PcUkkl//9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJJJf//R
9xWF9dQT0B2121/2vB9MkSN/2mrbOo0JifAaieEv+Dn/AJ9f/IqX/Bz/AM+v/kVf/9L1T/g5/wCf
X/yKl/wc/wDPr/5FS/4Of+fX/wAipf8ABz/z6/8AkVf/0/VP+Dn/AJ9f/IqX/Bz/AM+v/kVL/g5/
59f/ACKl/wAHP/Pr/wCRV//U9U/4Of8An1/8ipf8HP8Az6/+RUP6pjJGX9ZftbmHJPUmesKQRWD9
kx4DZJJG2CSY1kRAk9Cv/9X3FJJJf//W9xSSSX//1/cUkkl//9D3FJJJf//R9xSSSX//0vcUkkl/
/9P3FJf/2Q1lbmRzdHJlYW0NZW5kb2JqDTE0IDAgb2JqDTIzMTQ1DWVuZG9iag0xNyAwIG9iag08
PA0vTGVuZ3RoIDE4IDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIiYVV227T
QBD9gvzDPIKUGttrx07fWqVISEBBRPDCy8Yex1tcb9jdkPrvmb2lKVigSFG8tufMuczkMyxutwuW
pUkJjNVJXgJsN4sU7EftYfHmbQZZTocdHcK2Aft9glfwGrYPC+YuN/HyKs8ZFbpy5S7OUzpifx8V
AW7usas0yQqWecikzOrM49530Mij0rgE0wsNj7LFAU7yOLQwSgM7BA6deEJXMVvXoUOql9Z5rFes
69rXa0GOeA0ntGWpRtPzcY8gDBgJYmyGY4tw6kXT4y9UgaYt+7LVdLWKpets5UtzY5TYHQ1qW35E
bBP3er22vH1bM5pe+fv/lSet1xEyq4I6H+XJ6oLw84jaCDkGZXZEsZcnaKVtRYwalfH6fSfLNkIf
Bj7BhhsOH6ygdFrQY67Ul3c3n2Y8s6zLyNqjK9QHSbXt255qsU5eMo0c3Y3ZUFwyXLvkOYqF+0kg
35DYDILc8AQiQSB7JkCuJxCda/zr/ZbvBnx+Ap8Mji22l9bOEkuLPGobfhJwL1Bx1VAU+ADavbdi
SVVeBKxMY8ByVoUUGHVszFE51UWLCXzg0y70flDyIDWV67kGPijk7USN4khGjRTksXV33InXzSO+
VGlVsYDKirqMVjxgY4hqMPHAtVkChdFdafF4GEQjzATSaxXGCENLHtu9KLUWOzEIIyjHNBbzgq1Z
7KHMsyCY7DpUNKFi3xt45D/cVJ2kMr01QGEjnSLK4Tg/tE0sddRQPDl13g345MGnSGQ2J2XKLnMY
jA8RrP6ctnMGKz9n/9pMTt+yjK5WLKyNrSS/BpqoTirSimbnrxmyJHcYg+ac4DGTfkjlOEw2COPe
PkuzOT/mRQwVy6K950ibyz62N7fv776EoIWrBO4tCrfr7UDDQOoOYiQrg/EbQpkf7uwc5rKK29Lj
9vwXBnaUG9GJ55y9fXf3fgMtdmIUdv9ob0Je5v9YePbuH+s0rc6cy/Pce3TP9xkMB3zEMe5rD5cW
LwezYuWZCwsF3fhzL9MSRILJkhY9KhdTzSd97f9CVvlzrZnu77aL3zy69MMNZW5kc3RyZWFtDWVu
ZG9iag0xOCAwIG9iag03OTINZW5kb2JqDTEyIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQg
NSAwIFINL1Jlc291cmNlcyA8PA0vRm9udCA8PA0vRjEgOCAwIFIgDT4+DS9YT2JqZWN0IDw8DS9p
bTEgMTMgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgWyAxNSAwIFIgMTcgMCBS
ICBdDT4+DWVuZG9iag0yMiAwIG9iag08PA0vTGVuZ3RoIDIzIDAgUg0vRmlsdGVyIC9GbGF0ZURl
Y29kZSANPj4Nc3RyZWFtDQpIie1X627bNhR+grwD1wGDU8QySVGUFKwrnNgBjDlp0HjDfgQYFIuO
2cmmK8l1PfThx5tkSnFidygGDFsutkQd8pzv3L6ji8lJDEEIYy8AYDI4gUD95o/gpHeFAMJycSYX
wWQK1OcGdMApmHyQS93YC/Ue0LvCIPJwYGQ9X0t3fvxOC2opqOU63W57qQs9RHFkzvegT7BVcjUa
jgeAF6CcM5CyGV/ykoslEDOwmSelesKXIAFTka0XelkJlslDxoyBOPaVSbUaErggKkvs89ron/Ry
sNtpoevnNfiuj0OJv7HVHnw0auzHep+69iNqj++DGWdZChbJFsyTTwxgULCyUPh+7Y9/Gd6dg1cZ
e5wl2SuQLFPwKpmWa3VjMIeRY3nTsKdWHA0WYbVpF29lcuAHVdDCKKiwD8fD6+HNxEbvvjMY3l2+
H91ORu9u3p5ZBK/PwHh08/Pr+1OjH2PqvWyAkbD+1r7T/tK+8zEilfb+ZDIe3VntemuId3D3nx1a
bNXZmAQVMBRCCwzYn9FA/X0/ur4dj4Z6P4LoWY8PjnMvgi10UeBXFiDoNy1YyzIAl4P+pF+ZYbQg
Hx5wopFw1AS7ssOkpSZNyqTcrpgM4YMQGUuW4At4kKq/SAsK/rhk6cW2ZPK2mItcLfOl+szE8lF+
TedJrrX6AT2YXUbEMQxFdWFgnzYNU/r5VKTsUqqQd7NMJEpxKtaq8u3CpVisMva5Xrf396dNp/kR
PGidEXGsC8M6OhC33LbK2ZQXqk3tC1FADoVIS7ghiipdEEYtXRuelvP9qXAoEYJ271J1FLZy3QSQ
+J7btOqEscJsJgvi/fCqaUGEDwHF9NiEXyYL9o0SHqO4sp/QuFVX03SvFmnoVwB5KTeSPE+2Bf9z
P5qjc8PtwbFP6laFm9ps8c55mjJVu0vx+8c1y7fyssz54yPLnWKwfTg45FEj0UXEcL0ifh9YixTx
4ygO3A1yRkBhJSu9HtcdB8U0NJKyp2zEWjJeIRmvEAtWzrnsIRn/gxnPoOiJVW09XSPkKLMPhpMT
OcPYeUYSrnocQP2F1Y4Y5AzMTi70DBQgtGcGciYbl3mUyyvSPkR7BgeJd72md0Uax2KXNib9i/Hw
rQnJDvsTS2gUVtkc+5HZ+hzFStEX40pJkwRRULeFJ9xqSK05W2GKG9NVzb8oPpBS4Z7RwrQijYzi
lxjY6oCH5of/NsM2ioD4yhWEqraOSbMACA1sGJwK0ElP6nyAUfQtGVneGxSEujzTGKP0TG/KgTgp
V1lUZUib3En0YrCIaRn/PK+rnHOzul0nLu8rhxMU7oSfJ30UHMzOo8kw30/rX0mG/7P635j4/g2U
Tr1KVPYVbATbMr5X93MY4QoTCUL7ssY95p2BDTMvuYmElIJyzsBKFAV/4Bkvt6AU5ikEIgcLITuV
pkZgmoEP4e7dTqmJK2Y2V1JJxhZsWRaycxY8lVosP9vJ3uxvmkpRg8eYOcEzDaXty7qVtFy4xw3O
0hFik9faGFwzPEbUJsNAqOlIzkjFmcRzj7E/y5JSfhNwN+rfytIt1lkJZrlYALHOwW/X1yYTcOT0
TkJdlF0Dz+1AMAxxHTNsdd+wTSlbYMHyT3zKzvSMpoM2E1kmNtKwc5P2NNpFBrqaaoch/VK184Vi
G1TxDUSBKenOvCxX573e5yKROz7xrFglHivU/3kEI9hLuOh9KFa9gicrT15YqMhhRPnmZPtQ5+3t
u7s32JeIzmQTofQHVbdvZKVVNCk5EAeqE/sU6yMUjIogpR/03EjRU5Js5INvVdevkJJWcTvR5DBa
xdaPrH/vO2KZbY1HeV6UVTBXMuYly2Xtiwfl/KSUTCRrnRcg5cUqS7YsvT812OmTV6/WpIefzVVU
rSFn/CVuM0CNVkBbOKl7xr5zd/PIX+Ikq+UNZW5kc3RyZWFtDWVuZG9iag0yMyAwIG9iag0xNDM0
DWVuZG9iag0xOSAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMg
PDwNL0ZvbnQgPDwNL0YxIDggMCBSIA0vRjIgMjAgMCBSIA0vRjMgMjQgMCBSIA0vRjQgMjYgMCBS
IA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgMjIgMCBSDT4+DWVuZG9iag0zMyAwIG9i
ag08PA0vTGVuZ3RoIDM0IDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIie2X
e2/ayBqHP0G+gzd/VHQlzNw8l6jZyg3kHHSSwIJbdc92hVzipOwSiID0cj79mfGMjY3tBsfQQsuu
GrXxXN7r8/7mlXckgMUgtJljWV7zCFpA/j+7tY4a58QS+tc3R0D+HFrAhuqfn6ya9dzy/pa/rcud
KNwZ/c77NfkV2PqjOhSaYx2L6z03R3VgE0Edfbg++cXLcDNE4S+allwCIcbhErXc4Ugv/Hw3tj4G
s/loOjk9hjY41rdyqg7Xe4H8K06d/vK39Okgdjf2kPGUj9isNP+UDmN1Qd2EpmklI4aWrgEbJ49x
ElYlNjjJDUVXL4MnA4AIo8ZUgig0Qful2Tnz/ui2rDcdz3110Qr3C2oOaJzTVMwhR8ScgSkQ5s53
tTej4JPVnz7MhoF1M51ZNw/jsXU9HS6+3Ae2bb97roNHWHxuyn5MGE4GW8eaqkA9NdrKw7wqyl72
InOZTePrlM8I0biICDdOm3BFhRSewXhe3DFDLHnf6bEOBsxLLLCBoHp5TZamCVt6ZewIM47UjksX
Z116la7GKiECApp7EBXmnl6r33ndO2tZqgZ0eFA2PFCFNzc8KnWr3qhsOEhop2fB/GG8mOvsQ3vz
EcJIOfx9+vUJZeoQ42uz1T/rtbteu3Ol9+B0I2Vu+Fq/Nc5ZigAAAaQ3vb281DHlSZsAIJqbtbp2
bflR7aaYR73kCGCAfBV8WkwnVn90d69DSBI7BBbRDkSBwdY4sNp3/m1gucNhMJ9b3dl0MR1OxxJF
/bbbfffc6gezj6OhLjxIs5WXniayDClPT5PGSsF8k2ivSzcChCz4Jd92uDRlCjE2JdO+Ou+EaxHO
hV+B9yg5mFNpQBCQpCUT/06nHDk5QEjS5usYDjMMNdRqv79u9f4Y9D3Xe93XIIN5QFaoJ9Hpx5mA
pw3HjiBxWUNkytr66I8fjAMs94KCWZLFmloMoR5ctc5/ssviZDo0bkmBuCmYY6uhyxSBMpnKTGHE
NzWFicnGUqUgUTAXq3Ranewi9fP7CpmxWztvty6apmzKOFvcWMCBSTPazdxmydblIxWJeVSR7+ft
a20DrdxMRDBkPKTMYcbDh+F1dj49uZkgZ8SY/qo/MPHAJI8yZUyHUb6VG4iYgWhd+ws/1k26IktI
pyKkARQBYfjBn+m1Yj0PEo6uOEBRFHtMQBR7fzbzv8xH/zMOVLdeXoSJmSK/5nXcN8GZHGShaN6t
ufuDwAFRbpR9L7gJZsFkWFw96xao0qOIxw5m2ZBb/uU7CwpirGm6nju4aF/pievAIvasTQhkBp/k
A4zeVmvxoeTLU10VvePK8+ErhIsAoQgn1Xw+IXKfuGVd2BFIULZ72nz/GFHYapzp3NU8f3YbLAZX
keanoHKzfQslgTA1U/hN5+1J+IwdeKPFWDvBaMWBfOBFBV7QzJlyDaDRBAEMso2yggB+IMW2SCEP
Nu/A/sKfLWSTGVA4oOjsnRIVyKFiCQr17Oh7bs8beO3Llt4JcNVuO9Biz9QFQVjl4wCNLUEDCmxy
3JpcL5FRXEK7pS24IGlktK6aS2CIbEoPtPihaXHQF9VRkdtpmGJjcWeiMKHDgJcmqxo2KqEWFIjL
nZMc0HGcND+ar3uu1+5caX7k1vCTEKI2YVDAkMochA4yfowmi6/ke8vthzG0D7N6Ow1IkElcredm
l+1sfwnzJOl25Gz+fdBzB5duW3cXJ0Wzc/0BF6U8DFA4f9Yd0cXOAHvdCb3aLSWzkJzQag+I0rAy
oKunYjemM6ZM4UGofBzwsFk8QAcaPDRbZ3od28DwYrF+xIhEaXmyhi/EBDNdEGFC+rDkhABrcqKw
yw46ft9IwQ46fks6nptVV+7bVl+bICqDgggWjTGaoybKciKfcBQKK9bq7Tv/Nhhc+Z+DuRETFVts
G0qiWBZl5HpWzMllgEYaDTDIVjpsBSslGyxsrt1vMRUsGAXrPLVMfUJGXS6bD+5y88kSjpuvbZqP
Vx0Omx7SuZYjTHhO841M88E9aj4UM/t6+vB+rE/HoKIHP92EFnAvALLjM7ogwwA5hnn9M/eiVYoU
+SpYngkQjx3MzuhckfqE7gI4M6X7Q9+0GQeVpcaBFZVYQTNnPqYzqnICHCixFUqoShLU2NzpXbqe
DgTbC0EBEYCrnDifzu58rYf5BmQRjJ3AIMrUCiYqN1hIvKhyhh/8WW7LlGT11hiRzcTaYmK7jKCq
pA6YqIiJ/EZzoDCmyD4g+uzubHo/GwULf/bF0tfQaKipgoOp6vEXutxgYbmt15QJCSI3OWxdsjxh
bJMlWrq9TnfQdD0tohitIqISWFFREgVUKcnHEmDJV2kH8VEAFoLSj5Q1uj6Ru5XAYeOKrCVX2+bk
JCNxcO23zJGPeiBZaNWF2lHVXuBgUxKe++qiFVvtkI3bTJXkeMTqsPQ4N/u08SLfeAUqmnTV62X5
thnLwzdVKcuN6RAV2e7AVJq8ZnZ9WfMb52w50/QTSO8BECBK5E+oUwszN6TGoSIp5eZh+aKxEtRc
L0rb/+RehbL3dz4Thc6k9UuKmYAwnmrcX/48U934p0ZtmuhRwkE64cjRR9Q+LBb3J43G57lvfxyN
5/e+HczVnxMOOGj4o2nj7/l94342vX4YLmz595fT9/PJ9HRZKc8m/l1w2mlfuv9qPRsHH4Pxabfb
fxYYYopUQ+gpZO7+vAgm89F0cnru/feZvGIxHU7Hp//2vK4OLMgbTqt6DAkT5b/+0nGGTqlAr1YN
DUdVXVjfWjeGOsk0U5TZ7bRUyfmxg1K6cEiheEY1KyJ+lZGAoRgaWIQyRNrz9vLSanXbZ1b44LQt
z5/dBosT6xLjgWYoxI/U8G7mfbUvEMBhX/zcdaBeHGYLAgBo1RYPSfmRmGFYT3uy3Aa4YVviPZDZ
trQjfCAwZJKECTZ1J99dwDmB9ATI7TrS/DFY7kehQXqosh2qMghOEDuRmT9U2Y9bZZBThnSZ0bST
VUT/Rk1fN7ECH+RKKFc4NATBNnE4Bo5+HZDN5ff7POpgmN/4QfHT5ldAkyIs76QEEm20WJ/OO8ll
wA4yMyUA8vzbw8QybP/0aZUnQxSpLAS5NoY6wJJ/tPE4LxX7qK8A+tmz/Zjihohx/VUO3NR/rXA1
J0mLHznLwU5UV0SYCEmE5J8saO7JJlyZ85PvCpx5V+wnjhCDBx6FRUg1kGqjO/82aNyMFnMtFOGe
PwQg4IeXQKgUTYbVJZBpa5rB0JL6EQFg9AX8UeYOAt8p5aXjgzE18ek9MeP5IanLN8AyBDL/WmnE
VtkrDhSdknhk/WiHxFkwX8HKx8czWtzHKJqVnvvqotV0PVcXGc7jacXqr7PQkI0Zj6EwOI/tRmQL
XVsnJHzlbSzoAiZiru3mORKlstl8gzZDYizptfqd170zbTfh24g35RuNN2CEaGPedJYhJxuf6XUa
qrTY7MY5SEGZs9Ry2cbmq1oKl0uX37VT0QKIrEipGxgr/UyJPvTT9GF8bb0PhtO7wJrLH4sPo8mt
NR79E5zoCBGWxk7KdvW1DrHhcMIEEtkI4zglvkYbMpBqeUf/B5+GqHUNZW5kc3RyZWFtDWVuZG9i
ag0zNCAwIG9iag0yNjY3DWVuZG9iag0yOCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUg
MCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgMzcgMCBSDS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250ZW50
cyAzMyAwIFINPj4NZW5kb2JqDTM3IDAgb2JqDTw8DS9GMCA2IDAgUg0vRjEgOCAwIFINL0YyIDIw
IDAgUg0vRjQgMjYgMCBSDS9GNSAyOSAwIFINL0Y2IDMxIDAgUg0vRjcgMzUgMCBSDT4+DWVuZG9i
ag0zOSAwIG9iag08PA0vTGVuZ3RoIDQwIDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3Ry
ZWFtDQpIiexXbU/bSBf9BfkPXj5U6Upx5s0zNiqtAjHPEy0kbOKi7m5XkRsMzSovyHFaur9+x75j
xyYGEmICoaYiRY7vzJx7zz1z7qFTsZAmkKUbmuY0K0gL//lXWqV+jDVM5MNL+VBzBlr4+V2ram81
5x/5qGbpIorRcCqGaBweX1ZqSKfpEBp+gaKI9C5GJgIZppEOIjpJB+EoCOmEYSN9qHcforcx0pO3
dSzUO3JZok5yMx5p3zx/NpxODvawjvZgl8XBllb+8H5p5eTwKF7+nlOrJzWMWPjwWbOGTWuREWaq
1P3S7Bw5f5zZ2nnHaRye2NEKJlPx9WO+2EouwTFOUHOLq10/V8+H3netN537A0+7nPra5Xw00i6m
g+DHtafr+ue3kEZiJesamXWZMNNph6zzjVJOiICULyfi1m7vsrvpfLGfpJGgCxoZKmsqVzGZIJ5n
axXvJnB2t4O9uylVPxaLtGAdEyhYFetA1BS/CRLwHYq+MvJqvkQUSggE7UGGrTx63ZlkyWIjDKiZ
OjE2yyqsDFnFAgK6dq/zsXtkayFpIBjry6DSOLIpzUWTSWnYBAROWfW92XwUzIA+Rs5GhWcPEz2d
vOeQgPwapXbIlIkwQ5GsafeOuq0zp9VpA91YPtmTDe5s4Vv1kHoL/VX9dHoKjSEWZ49khqkmqEE6
UlptxrkWzAJAbe97MJ1oveH4euRprbF75WmNwcCbzbQzfxpMB9ORVKteq3H2+a3W8/xvwwFQTYpj
HqKlPKNbN099+eZ56gyuI4JUbv+8l846qmAiDtBb7eMOrIqyyz6QAZqzbi0UcYLTh5i4Y6g6wfcJ
9upSLROIMYOg3z/a3T/6PafhfOxBpc0VxIXgRFyWapAFg5jJE/zIUsTXvrmjuQJFClZNrFOVkM5v
6h5/uFEEVnXXEaYEdtzT6spP8U39lEU2v9mBE9WF7SHF92SN8uyV+cJ7kFFiAdTjln3ShGXpWk2Y
PkVmbcvMdGGrmce/jbqQU6rktvNl1rq4ux0e336ECaGILe8MRWxtPoDNcNF+hVpY1aNz2OurlFFU
FCAJgnARVxKbRgzowg3cxIfRXGu7GTDGYqINvrp+nipsCkyqfgJMxM5dc33f/TEb/quQicIdZmLM
f13DmN+vluKx/ZfMQiZOzUKlBD2hBFHE1Okd17/ygn7bHUfBjGV8LVFzZRWIyIqkPjFIMrRSjGLq
L0Sq+HaWcBTtzzuf9iPj3XeGwUgNcrm0KDWr1Kx7RhcWdtvODC+7rVqyfdX40gtcP5CtqyYkhp7X
PaXwZGm9EirC2EKUQgMlx7Ku03dap2D4zVzDv3O6hLhY0qVcjX/8jYJQMnQSw8L5wmTmtdGLU6ZN
Z09qsNJJbUOTkCpj1Z5cLBSJ8qUNdsoocU6zmmS3mwtFEqJQp4RiBoSHtjDLV6SCIT65TUKUplCR
GNUKNmmz6+QFahEjpRZtY6rjyICgziQlRbQoTm/dGjHEeVqGIMFWOsMUEYW5129+7DacVqcNntAs
1Fs8i0bJSNXMw0lwN1223M5E8LKdt9DOhmWo03cbEIQLvHa3P+cYRDXzWUf6id/73Ub/tNGCbuW5
rny3urV0FNtzFCjiS6lCW1Ch5A5q2keFk/oxKrTpaIOsjAxJWAsdErTIhsWEi7ik2DRibLdkqPjx
DXGxpES5U+LjZ1KEeIyMGBbOl6JcUd+wfC9QjOTqpRJtYbyxuLL6x53z4km9fUNERWq6OR56o4t+
57J/PvS+Qw2t3VeiJ/dEr0mIxGM7caFEoSeCDUsxelIxYrESdU8bDuQR7bQYcSMlRq2xe+X1j6f+
2A3AF5FSix4GhgVJgAnDzNeivPnsFUoRJeWEtiUpQkooql3v0vO9yeC+HtqZQY1BB4WDZ8Np9E9a
7d+iWEYKnWRKNXr9amQ7FRxpUBhncc1gUdawxcJXI1C+p11WDp2KheS34U3YrJSi9YSiheOKV+2b
6+ls7nt9x/0yAlYaYvf7m1pYHTBIcGFzFel6oBl4TnLXuZkJInpyMeeSL0wv4jHJ5c87pfB35RgJ
y0inKRRs2B7nUybZqvo+y/CHEdVk7655/Pj84i66E0xF+vxO4/DETkAw8UCzPgKECFukFo2lBeLg
JsvA6Oa1YxHHp1G7Lc5fmFTKvTg3UpAhELPN9dKIBcNpbpaW242OGYhlFWFEOEMANaOtyZ2IEb4H
0JISIAx9VX1XXzrzLXNGzAy6O7R6g6LnSAmWkrCGx4cokXs5ZDiAo5tNUWAlOM9Yf2Li5IKxBFJ6
/en0VLPPWkdaa+xeebrmuP6VF+xrp5T2FQWwtRYHYogvkwmmiJgABy9UEAjDaUEA9OSFkoFaTHUs
QQgtXfphMnn8Rg1SsCwSyITCrRIkJzF1W2D5VuzyEdOQsY/5PpKxYKnICrPFjnDNoD+75myfZkTQ
hGaI0oRmGO0TsY/Ja6QZKy83asTGxeSCQKrY6gV+oaW1omc/eWkJY1RpCNWZYVJkQNPnnnnXSoyR
WRbYgvep3I8zzKC8xquYPBBd02++0hpTrJoY6YLchB9QZbHOPfxii2yE2/zkbcwErCudF2XK3ze9
gSZrJ80flJvx12O7MCuLLtNiqoWHY/fKq18Og9nP29iAPHuy3BoTho1FkSEOk5dS4ztTVEv70fSa
hHCcOeYvfx01G07jL+h6kp8SlKE95ur4X4Pger9ev5m5+rfhaHbt6t4s/N03kYnq7nBa/2d2Xb/2
pxfzQaDLvz9Mv8wm0wOEEeFMfuI3E3fsHXRap43/2W9G3jdvdHB21nvj3QTeZDacTg6OnT/fACI4
WwxJR8JUZkSuH0wH09HB/x3nDGCIBx2JhIHiSeTvvyG/mOb0/FpTgKXVzPDxcwmNYGauIONUPrbN
RFa2ZQLNdio4SkP4lrqXqCDwn9wsKqvvaZeVQ6diIfnQUH60UmDyEIlvfS3+AUbj1ROY2iaTQyyw
ymHj8MSGZVnhN0CNK31b3a2vnB3MuXErOyo9bEN+MUqUZB237BPgGKFZqVpddLJrW2ZG1lv33L3h
sjSm+sFe3ov5DsI0VG3tm+vpbO577fn4i+cDYrLKEEhwvO/eUj1uuQgmQJ1lik2LqBzMBxfQmcZD
wFQe1oJHlcWxP531VQKJyNvokbBCIeciLi02jRjWhRu4wY9rD4J58dgYi5k3+OpCwfAqBn9lYIhS
K+GsJTsFgLm+7/6YDf/17naa8tLC2RZSuG6pb37NkLrCf41CjFU4iARW2+kIU1WCPa3+Pi8t63sA
ysJzF3/jlbJ0BweoiTkEtcLBpt+WjhJcoFUcw1dQpIKZTaii9nnn0z4gc4bBCKBxXGTzlqr0+lUp
YkypSttTJaL2qLYms8Cfj71JAKqEt2uUCqY2s6iC1e45sUuipRyVcrSWHEEnl3q0PT1iJoOgXuD6
gfQSsUvaaT3iTBVFuqQlauqYWmqk2+8c9vo9p9F1+k7r1IY6mwUij8qS6m4cd/ct2So1a2c1Sxjh
ZqVmbXGyi82GPblYKFb+3b8rikVwrEnhYBfKkt1uLkRJFNq9pZUqGNjauiRzQUwSH5WZ3LytS+Kx
/biY7SgIE+xZatNWtIlbyk81574bDKcTyCnZZTdFLCay2tT82G04rU77v/artqdtJAj/gvwHXz+g
6qQk++5ddPQUIPRyBy0NVnW6qorcYGiqvF1iWnq//mZfbOzEgVDcEJAr6jjxrneeeWaembHaJMtM
4EfolmCnwzcYx6tjYsONBVGiGoY2mryCCVeDj96+L706bT5tfecyk7ZHg2h43rMGZp3RILb4wLK3
F733g+ib5UGVOgVVHUfJ3G7hIAS6XInVxsSKK+7M77YsgbjUjCWc0AQ3xUguiVX5yUqRcLadvoX5
512v2+qdtDq2yxCyEqRnNQLdrUgPH4EoqiRpg5KU9tGH7YPH6J/KT1cikMpJEiC70SSflpu5jzD7
bLEePb8GyRBSCdIGBSmd57onrcA6FD/lkY75wktHus4ovIx6R5PZyFLI0hfoKOLJ9BfG9nGRZ6v+
qdKrlXrFTabXlT2ykqxNSBYlzI5dL7vRRTSLxv3bculpTXfK2XbYClq9486bv8xeRipVKkmVZJFq
bN1Y90Bdagc1ZKRI78MwJMLBRJgMx1J4BtQs8i5q+0FNIXjEG0a+apV8/Xz5IkS5BuVscjXrR70g
/DS00clUmQnxWJlOFXYGxikyLNfR5o1kBc5lBWd6HUES3r2UF1xUebG5vEDKjSLtcTS7/N7bD8fn
meTwn0ER3NbUqBOqE6CuVgeg9hSjSReU+WdDkt5MVgvjH01GTOeuw6UqCZJIHfXQ9qxuDTLWvHyV
T4S7QdeFgV03DUDJKGETRTQLMmjtH7cPEzSsfDTS/zlsISFyOLqrE/1hADjK01GixCIu1DJytx/d
ASUvtMUCoqWGOOTBLVK4jocWFIIj7JoDhLDNVrRWQ4mwS6HfmjaD0CqKSzP9PgKDkZmXXMxWZCfz
XlqGlI/dyPL3yYnXPu0cwOWN1xmFl1HDC8LZZRTveicUH0xm8EP7ejqZX0GzkokTvH6UJMC3MlaI
FI0qVBZ0gUrXOUBUWNL4Wn3D1usCNnVAWZsrvhNpUMzxRhBCS42iqdTJirpFlBpIkFWVl0gu2nTr
PniSdg+KIdc9IJhLxC78MdqwhnB8r8jbaq3BPq7q0jYEn0DE1ULcAHv9m+BTu0ujrG5vEc9NYRzv
cuIClMiCfvvJKWMVmQWRyV10YcqRsq5jT59qpKqGZ4FpQjF1QtLwybW+WLv955DbhFZ05xOb+C6z
QecZlxRxa3fhAU+Pb151uUWss+TFYKkQDDNrNr9x4VMmHVUFfEnWeTLHDkbhZdS8GMTzZ6nrukMl
pIAmxxNdn6QCgACbkBy+rCfKwVfHpiuRGubiawkROGfpLx8ODltB64PZyUhxFKNsJEDT4xB8juPp
brN5PQ8bXwfD+TRsRHP9f1ciiZrhYNL8Mp82p7PJ+VU/bnyx8YIhYG5EooE5dfVj+vvk03w82UPg
f8HgincG43k8DkfR3umbnfMwDudXn+ZRDGvkjvm5c9J63XaYJcowSIVzXm9nGH2Nhnunp2c70XUc
jeeDyXjvKPhnB8yKJ/3JcO+PIDi1lrE7OlIzvDhrP3585eA0lj12r9BT3KhNSleZguP7y4JjDRFF
Sp3N1CRAXL7iLGkbTtg6ON1xayxEsiQVfaQEbQc1ZGjWqzAxDpMcTjFaagJhFnkXtf2gppAndcQd
1rJnI6L8IoVK3ZDl4H4lBJb72OFv7R+33ahWPqfQLpKfEva3p92PRgWjRFmoR532sY0MC+FHkj//
biVzmty5NY98nPh870VRfBZWb4ax23Q2uZr1o875qmK26EqCk3R4seT/BR1gbhIAx0qVVNCrvj0K
34rFIb8HIhgzHR9n3YOecxmRa/QiayICFET4CZdY8gSRLkTx92lkN4siljT51J2Sh6aKwzdPFktC
rf85nFmPiDKBIUpVGqSKMAcsnM3C7/PBf9Hqvu5hlCFXO381W9abFXwXuHCLqaPghdd8VeSWexdf
EOJ/QYHd+dqFArH0sz8ygLn3Ta/5U1++eDV7UPe1p7WZM+XBKl83XBwCEvp7JuGDeoyDi/teDUqX
ppNpS6lksMOjwj4SyKPc1GGp45YK4UHrow9MVpx5tXdwLDLFlwpD6Ej/IM2SIdhgAor6ZsVQP3Iv
0OzB989e7eLXh4DE2PeI0MUJFirDGYHyAh++7nwIphotlgy+GLwEbjAXHtOPMcYasUqeWgjGXcqc
KrG+wsRlC2AGNDaHSD15GMxE2CVDY5PZa676ux3YJHPfHw4aDiNcONAmHgk3jjV+JcA6oCIEOZOZ
vsFKI2bEw0z7gDFtuUV5A4sZohTVL2Y8RcSMR6i5TTalQP4HOlXipw1lbmRzdHJlYW0NZW5kb2Jq
DTQwIDAgb2JqDTQ0MjQNZW5kb2JqDTM4IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAw
IFINL1Jlc291cmNlcyA8PA0vRm9udCA0MSAwIFINL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRz
IDM5IDAgUg0+Pg1lbmRvYmoNNDEgMCBvYmoNPDwNL0YwIDYgMCBSDS9GMSA4IDAgUg0vRjIgMjAg
MCBSDS9GNSAyOSAwIFINL0Y2IDMxIDAgUg0vRjcgMzUgMCBSDT4+DWVuZG9iag00MyAwIG9iag08
PA0vTGVuZ3RoIDQ0IDAgUg0vRmlsdGVyIC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIiexXf2/a
yBb9BPkO3vyBeFth5veMo01XJJCW3YTwiFXlvapCXuKkdAkgbPqa/fRv7BkbGxwSwJCQOigIgWfm
nnvPPXPuiX0ACTE4xCaihmHXD6AB5GtyZxxUz5DBTB58fXsA5HvPqAATyw//M8rGvwz72wEOfg5+
qoeronV0tk6uAFTQ5CIUHDVbBMNFwISEi/AQoB7+LXyYRU+aLD4AmAQjK3y2fNZsnNfVtji9r342
intZFKm9LQGTYTTV7lYaaRQ0hzro8vFh+BwEZlZGeCKTJgaMqUXNe+fO7bacezdcTETWKfP5RBAh
tfxwoQgJJMGThHOFxYTCQhr+tHejQl0KSMNfARbkWJ1W/nR5faSg2X1/oLAxaOYGTZ6FGI8qCwWN
oN04vuM/jNWJmGVlM6AC1qekMVrZZE5hJCQiXu+rM1GpYXkCAxhbMWUtRDQwZzJxHrz+PxoZzzhy
o9ohoEv3a7iEZrXoQl9zKCJ2YaFLcGiEf9X3qslExtHPaUn9TQVTGJxYscJvH9GmQpXyUCUEmY7e
jjpI1jc3YiOKcHyHQCAWxCj/ZsU0QnTVOe3qlCHrOdwuhGh9IdoM2MpKJHOBBIpCJYKJSIm0CEG+
bgtGKoQ4K1RoRyoUlb/j3nhf+7e+yiXIi9g7d0XI4trsdRr1q4/NM7vb/nhpF55oBWCQx/0NOY2u
jtcnRWlTBCCOTVEkRWxTP4SCm1QqkTqyEKOtihG1qI6+U1OLYI7mYfdSRJGWovblVbfx726n1r2o
NVuqfiJXXwSiwof2AUb2YU6Mcm5YSiGKlUilBc/SEuiI5oBSKZwn3H0c27aiUEAohSrkaevyhJAu
f71xmvu9u448bXjfMmCl9EnCmgkUx2/BLAHGF8wSzTpmbWQIABYhQ9SC2VKUqfZvzy7J3Qsl2sHU
BqPoPzgDp+f3e6ejwfR+WHeHXt9/CPcR6GW1aaOLFlpU5bD86fL6KALZVSi7SZgQWG9Bp7Y91D1G
4gomQf500yaMlYYwJ2OZIrMuiV+ffjEY5CLU6k3EBW5RXBDOFJfcioKZDr02vJsOnMnl7a3n+uF6
kmunyekIR+gxBGJBUfJvMoQwVbE1W1d2t9b60L08O6tdN6+U4yG5jmSQ6AcroUngaSlRa1NlBjDF
MNVyJCPnySy8JpHZYCzbsRWSuUAirg4RTMxLCV+3XWNhpSQ4rbBD27dDRId+2bmo2SqPIEePv3P3
gxhVI0Xofpr3zp3bPRtN7h2lwxzlKFJv1O+YEPK4vyGn0fXy+qToaVezuRSpe6aQoh1IEdBCUe64
t+7EHfaW9dAOBWnDdlUdJAOr1+xa97zZ+lO5E5QjrEKNfgo1QpaVUKN1ZQJwi84Yqc6C2Y0cb1t+
n97w6fCldCZM3PrzIFCjTtmunZw34oBJFsc2i5eKHCbYYGOmHYjdWaaRm4QKQ+2YxfrK7yUatbpd
z7oNnp+R+RZNSAMmUb/B64sL4w/Zf1hKLHwnCSRfqhJZE+ECfgBpClh1Iea5+wSJFLr8652hBJBC
c19sybbKT6z4xrMsfS8EtW+3jKvRdKLtA+VxUJDPVjAR6nuAcwlhnqf6e8EYBPTdoSL/aVmDIdaG
ZTgdDNTWeBVdeKK+OUa+Snk53J85pShtUdpVr3pO9MZyoCVwiWldt7gvpctcJGzyT19dLHcERXXf
VnUtriciYZLGO6TqizMj3rf6isJUhSVmWD1PuUTKVbjsTRQYF5cvlvqsFvTvnTu3Or65VThZnhL9
Qu5KUDOu73qJ3wk1KyzMaUUECOb3RYjBVKy/fD6t1+za53CpnGoz+QiSNYaQ6Sp99f3xUbX6w3PM
7/2BN3ZM1wv+jwQQoOr0R9Vv3rg6noxupj3flJ9/H/3lDUfHAALEiHyHJW80nfTclnPvHv8BINZy
gBJlBxbWdwKW4cF3GASvUn/o+cNgWbulUGNAE/0XZJDqDJbC55oXtQ+NbmngfncHx+32Vfeqc1py
f/ju0OuPhsft+llJRuqPeqPB8Ufbbmtr8fTdI48ClKujvnx5nzVMrM41KHCigjtXk2QzRkzRLQkT
zy+ndv5NWaHwJU3SWlkBTNPX7myr4THeo5RIqLKBdUpqJ+eNQH6U+rDc+cIsxZcXM13r5AdwSwts
nJrsEWfD3OwZazhMkEbtTfLPilTy/cnKbkRXpfn1G5+GfRDso3aCmBpERk4N5T0tY+Iatwcntv5F
V6d+sK6F3hEfEX/JG2+1lBCMLIXzrNk4V2VGOL3v861Qem9LwGQYzaUk4jBK+PFhVlc8MrsQPbs0
hu7k7uHEGd40b8LlFC4cMp9O6RT1SHK4UIO5RiBcuUWZXGEhjX7aU0fBpXg0+hVQIWnXNapWo/Ph
P92TWqve1eljPEMs1kQm0SDGo7pCQSNkN47v+A9jd8kgGBAB61PSEK1sKqcgEhLRrvfVmajMZFmJ
tYEBjK2YsBYiGpgzmTgPXv8fjSwrl5uVDuip4ldFwicnkSA8DvVxphyndAkOjer7rLSsPpZgIgot
2oEWERrdLs17504ts2bLJDWYttButyWnWxWv9RyGvFahghxrun+6vD4KYLtdu+8PFDYGC6UqlGoV
pcJWYZx2I1ZIIC1Gyjh1nOGdYpq8LfZWjgQQMzlqf33wugpddwbPKkSpEKWVRIlZhSLtwj7p0C87
FzVb5RFkbb8vYoQYZTMxUt7obDS5d/xwC44KFXoaGOQoBsapeL4KbQZsCzLE1+3DmTkKv6xY6sxC
jbarRkBrRbnj3roTd9hb1kYbaBJDVLMGgeiWnfbm4wz3FCk6K9UiT3B/pXZWHSYX1Wt2rXvebP2p
zkA5Yi7U6udQKyCUWm2kIYBbdMZIdRbM7vJ42/L79IZPhy+lNRw7w4g3CRdioIcqu3Zy3ohjJlk0
2yxkKszNIw42Ztqk2J1lGrpJqKpi+2GhadTqdj3rqnh+Oh5rUbJCiwKoyf9bdSGY7US9Socz/LPX
lKvyVKAJKVRxXF9cGI1281S+tYzQ85uG7UzuXP/IuMC4y6rywtbjBjDiux0wQpNwKiphMRxAsaaC
vD3+dj+p1JDnXMvPZVFw0SGRSlT+WpBBI4RJIQ+AaWcSsyNhuZL8mGNGJbDZMGaGXrr3nBAFJUwI
tN0v9wMZqd72fW+FCeS1l9hSliseZtc2MNuPHpLQyWZ6LYQYTIX6y+fTwPZ9zhycokKDVKGxduLl
r74/PqpWf3iO+b0/8MaO6XrB/5EAAlSd/qj6zRtXx5PRzbTnm/Lz76O/vOHoWI8yCZM5m7HKAALE
CGAAlvpDzx869+5xu1Vyf4zlyitJk5LWYYbnYMrIhDaHwWzmTf/yXF8uIiVvNJ30XPkRAFAKd2xe
1D40uqWB+90dHLfbV3J/3x16/dHw+Mz+b0nG7I96o8HxR9tuK0oI8SSNgyagGsaXL3oyweZiRle6
b0SQp5fSlmRnRpTR/QkTzy+neP72LpqA9ikrG08uj+ciSoT8FQqW0iJzEcWjc0+6n/LY7JWGlZJG
VSD9ANgyp+SfKn5G5TkRq1BK9hnEWm3s2sl5I9BxJeP8CZuwRsNxnijoK0oOyswM4JZ2E3FSEMz9
om3YB8E+aidIQ1QIhNcSQUbY3xPXuD04seWdTORP1Axpd/CK8vcouSCHCW4tGeA245W0jdtX8lwT
k5uBfjwpBJhJr7kPWWGCpG63lbPyRC7+X3615EQMw9AT5A5eIhYosZM0OQESOz43GAkhxCxYcX3i
N0laUKfzUWeExCZpmqfYlu1n+48XklWLZe8tgB2au5oPDhSDKv7yJSGmfXPGETZMYnWeuasZF+Zv
h+RSVPYlzpxou+4R5bmTdy7SJNRsNKPwm5pAvof6QmM4P85ejWd9mNDsSZ6a0Vqj3coPM1+ADmOU
KTsFblX49+1qc4C7OzsEF3msmXUmm52s+X/ptg8OUHvzRKxMEmVktri6a6IsJ8qRGl+tCf2k2lE6
BXC0vu+bLap5oC/FPOjyTmb37NM9KbXFMpdu8RVSIt1sBv9Z8oOF7za49qKWJlaGlKFBeNemKAR9
hmch5wBi+N9xxk+FPJN5LDrwAJZNZS2SC7cC8NFvGC/hnNub5fRG5vXWfAMJyW1DDWVuZHN0cmVh
bQ1lbmRvYmoNNDQgMCBvYmoNMzA3Ng1lbmRvYmoNNDIgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1Bh
cmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250IDw8DS9GMCA2IDAgUiANL0YyIDIwIDAgUiAN
L0Y1IDI5IDAgUiANL0Y3IDM1IDAgUiANPj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDQz
IDAgUg0+Pg1lbmRvYmoNNDcgMCBvYmoNPDwNL0xlbmd0aCA0OCAwIFINL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgDT4+DXN0cmVhbQ0KSImtlM1O3DAUhZ9g3uEuoWKC7cT5kapKhRkkEBUShK7YeCYmCc3E
keOBztv32k4gw08XLTvHPr738/GJT/JZRiChYcA4QL6YESBAQZcwOz7jEAeJnb6fzUlACLXjNQog
f4KDr8eHkD/MKAm4m1oACWKw++1uEtCEOvlB/v3kcum0LLL1BvFzI5RGSeq135wunmiGcm7ZUvCU
+/7gpPOIWvR5OhxgUvcfmBnPQg9yvby5ur0+9dwR+2RoniLAPPt/YJqwzEP8vHrxOYw/m5dZ3iTw
Fh+f0b1k0DTZkxOYU+bXvZgyJyWvReFQcDIVjff4sSz/YhkpSfxVoTV+iKXPDdQ9PCltKmiVqdsS
6hZMhZMbVcjmCMfCwErhuqkk3KitXsseRFu472Urdbk7wU+c0/IdLOtOTNOhc0jdEDuLstSyFKZW
bQ/q3lXrxUaC/N2pfou11o3o+wByC1MobIqAgGsSu++g02rVyM1r3Dce2JPHfOwfUT72711LlwEo
3Da8bvLCnLGRmSfJsMcI27eTutlBIRFQy8ITSDg7X14usKhALKikKKQ+gm5r7OLGOyjcxxAR7LZv
E2PhiJkl4YDpLGnko2wCt427h2cM4iT4Y/Dc+rtJmThCUjKeLiJ0ON1pU8vW2DRsmwJUi2esxKME
o8BoHGh03uJXtdRCr6udS0FR910jdlAbEJ01R9fCSNx7dyCDMjiC1e6DVFAejQ5nJPIM9abDS0UM
m0QBi6sfw+/MXx5Ca1UUT88+949OwKf3x5KhOkvH+2vqXxI6oXtbfcgcPgPuxnqjt2tjc2dP1WH0
rMgq1OpBrs3gL6Vk32Cbryya0hS19tBsj5nEyfNfkLpwoRYLo1XocK82EnOMLR2kgItcS2mzdSEe
xd2hv32a0b9fP0Mj374Jy3z2B94NpUYNZW5kc3RyZWFtDWVuZG9iag00OCAwIG9iag02ODkNZW5k
b2JqDTQ1IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNDYgMCBSDS9SZXNvdXJjZXMgPDwN
L0ZvbnQgPDwNL0YxIDggMCBSIA0vRjUgMjkgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29u
dGVudHMgNDcgMCBSDT4+DWVuZG9iag01MCAwIG9iag08PA0vTGVuZ3RoIDUxIDAgUg0vRmlsdGVy
IC9GbGF0ZURlY29kZSANPj4Nc3RyZWFtDQpIia1X224bNxD9Av8DH5PCVvZ+SZ/s2kENtKgBKwgK
+IXapSQmq6XM3ZWifn1nhpeV1lILBEGAYE2RnMs5c2Z4N78qA5YH5SxlbH5/FTD8p1fs6sOnkIUR
LC5hkc0rhv/v2Tv2ns2/wtJNGJsz7MOnYLJzFiVlbLY/D5sN1wemlqxfC7ZRtWjohgeynMG+MMxZ
CHdpwZZXd/OrKMhhPbP+vDF9g/tvwmQWGfN2OSxOXPLO36A3GV3z7oZ2xrM8pSvvmbne3UBXmh/g
VJAkkQ0nLOkTXHjsWa1Ex1rVs60WvWhr1itWi6VsBeMmPgyWtwcmvsuul+0KdqqvouqZ0qfrPpU+
GLSbQSg2jVmWGLvb9aGTFW/Y68DbXvaHGQNXVNscnBsd+sGbRu3ZEux0vR6qfoCc1rLbNvzAZMue
H2+fTAqSdEzCUYZsok2e0pN0hEWeunSYT9jYyG/CohKn4REAeCCM4+NLXwehpehmxoHsAgg3aYK/
nNz0g/ilqbGPvsTRCCAlqSM6utzQ+bI8OpwHDvw4LkJz1sLaH7YCIR5TDKnlrNdCMEoI5H8zY3O4
n3dbwt2Q3wQIZiaAl0libSVZaQGn22RnmVWzxYGueImi+N44DZ8Ju+c9Z38S6fo172kPrT1ptZO1
0GwPfCFuvKlbzEtUOq6lOX2CadlWzVBTVBKOEmugOLutajsxs6kOTxCYFGg6DfEHETSoEeWSPJsC
iDTfDE0vtw1kerXSYsV7qVoojZYSIb7zDf22UDtxzRaqX9P6sxp0BRAuqCjP5SXKM1eCzi6HSqet
UTCRidSXaxxb1UMrD63Qq8MdnrOWuB79BA2xrOj4BjZ/36oOqWS2ztgdOruXTWNzaqyeOBnkcegs
l3Fu3dxuBdeIHUV6DB2wkc1v7/546Jjg1RrUQ4AFMIMoq33LHu9JVcgqnG7ZQpyXqDCIXH6SNLIJ
GrbIMrRaNVK0PemirS9Y3TifKN6F5m21piLRxPNWMchAJxeNOM/UNC+OqVapdjl0iDbtTrCBnZOT
LJ+lP4eMYen0L8rK9G070GJJ57LsRFqDrPBKkgSl1U2iA2hJDbW64IDNVwXpgT4B8W+uEal+DVkx
7eRNxzF+B8HUc5sbUIbMirIN/5g1RZhbf+wnsqbRgtcHkDRgZm3COJX/sx0imZ0UQuEujtLYyi2S
wAThosUgjTJpAYjLXuF0oNmbDgdZcKHeZOWbphBkgTdXhL7uhm5M15rvBDpQUeEt1ABL0B6RhBBu
Y9x5eWd56aEAZ/agpWIn9Mt75OaFGshc3SdFaKVT6RVv5T+i/ghFZQqJejR6YEgVFRP18COGTZjx
kwrF95eV3EE1nqvpa3BVQi1b4TW3T1SiLB3/otJa6dZqaGqkrGEiwz4ll7L6jwZjCi2K8jGAc+If
Janx4SeU3Oh6EjiIH3sKHtw2Lfzzb/dsyzWv5Qqa7i2wzKqtg9VKEIFtqLin4Ikd56QmSMbWH9hC
BxZBH66Bkky8DnLHG1Q4tE3TX1dpCWLpOvT876cHyh5IvPMG3Yb67eBcd81aOwVFpzOWp5T5Qkb1
br4ye089TWPfp7LcYvvl99s5eeIsd0blwXglSTHZFxBgASKN5eGmhm+t2jeiXq1pttm75fMjalG6
zpPEqQVmNLeRq3WPzaMCAksoNOzUnK0atYA/jkYWnxEchtHafq0u6H/g9X8W54E1yaFE1FQ4YMZ0
2H9uoXA0VskCagolASc1nB7QoK+v2pMEHb1Q7cFJ+8EitAVRXOg8STaV3h+rgsjnOsvGGciKnJHh
fFI2mVOVuCgsKyD0DcitIB2GpPdaVjgsgT5dKpMWGnUH+ohJGcdXY2yCTeJbo5+XDB26l/dmEjYz
AYoz4XAkyXi1MWUHoloulzAVQH2tpdBcV2uC98JjKXFdIPZNxwOLROig1wD5nGB+RBOHUZWtE57v
Z/Jwlo6l76Jx4rooRoH8N3T3kuqmPwtufFry8LzwE7jTOBAa79AWBoMeuqWdrVwLrQeqNZNcxNM3
qhtrYpKoowdNGibTke2kM9MADTOyG6CvactSarByKq4OoANaB5BAQM6nK/OTfBLE9jn116ITekcj
O6VMLXZSQf+G3twBVPRg3XIY1LEr4xBttit6RbLf1R479LVzhczOf7EvP/9uKAJHCgTnaB4F6Cvq
AwukB4SOcRmI8vy4mHIHdBJax1Gmuv9LiL/cggLXTJ99mbs5TQuLvM0hNpEnBB50yjQSbdYa/joI
t+KmFJrapZl5sMp1D0I4MggmSVC78yzO/BzvZwMAveobRNTIpu8G+OyVZIgTQTGFZxhKo5Xc8JUY
Z6vztTsqelS48DtqPyivv1IFQSn7l4P/9fmWBjM3kUSXx5GH+dW/nnkxWA1lbmRzdHJlYW0NZW5k
b2JqDTUxIDAgb2JqDTE3ODQNZW5kb2JqDTQ5IDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQg
NDYgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0vRjEgOCAwIFIgDT4+DS9Q
cm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyA1MCAwIFINPj4NZW5kb2JqDTYgMCBvYmoNPDwNL1R5
cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMA0vQmFzZUZvbnQgL1RpbWVzTmV3
Um9tYW4sQm9sZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDI1MCAzMzMg
NTU1IDUwMCA1MDAgMTAwMCA4MzMgMjc4IDMzMyAzMzMgNTAwIDU3MCAyNTAgMzMzIDI1MCAyNzgg
DTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDU3MCA1NzAg
NTcwIDUwMCANOTMwIDcyMiA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5IDUwMCA3Nzgg
NjY3IDk0NCA3MjIgNzc4IA02MTEgNzc4IDcyMiA1NTYgNjY3IDcyMiA3MjIgMTAwMCA3MjIgNzIy
IDY2NyAzMzMgMjc4IDMzMyA1ODEgNTAwIA0zMzMgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAw
IDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1MDAgDTU1NiA1NTYgNDQ0IDM4OSAzMzMgNTU2
IDUwMCA3MjIgNTAwIDUwMCA0NDQgMzk0IDIyMCAzOTQgNTIwIDc3OCANNTAwIDc3OCAzMzMgNTAw
IDUwMCAxMDAwIDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMzMyAxMDAwIDc3OCA2NjcgNzc4IA03Nzgg
MzMzIDMzMyA1MDAgNTAwIDM1MCA1MDAgMTAwMCAzMzMgMTAwMCAzODkgMzMzIDcyMiA3NzggNDQ0
IDcyMiANMjUwIDMzMyA1MDAgNTAwIDUwMCA1MDAgMjIwIDUwMCAzMzMgNzQ3IDMwMCA1MDAgNTcw
IDMzMyA3NDcgNTAwIA00MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA1NDAgMjUwIDMzMyAzMDAgMzMw
IDUwMCA3NTAgNzUwIDc1MCA1MDAgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2
NyA2NjcgNjY3IDY2NyAzODkgMzg5IDM4OSAzODkgDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3
OCA1NzAgNzc4IDcyMiA3MjIgNzIyIDcyMiA3MjIgNjExIDU1NiANNTAwIDUwMCA1MDAgNTAwIDUw
MCA1MDAgNzIyIDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTU2IDUw
MCA1MDAgNTAwIDUwMCA1MDAgNTQ5IDUwMCA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgDV0N
L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDcgMCBSDT4+DWVuZG9i
ag03IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1RpbWVzTmV3Um9t
YW4sQm9sZA0vRmxhZ3MgMTY0MTgNL0ZvbnRCQm94IFsgLTI1MCAtMjE2IDExNjUgMTAwMCBdDS9N
aXNzaW5nV2lkdGggMzIzDS9TdGVtViAxMzYNL1N0ZW1IIDEzNg0vSXRhbGljQW5nbGUgMA0vQ2Fw
SGVpZ2h0IDg5MQ0vWEhlaWdodCA0NDYNL0FzY2VudCA4OTENL0Rlc2NlbnQgLTIxNg0vTGVhZGlu
ZyAxNDkNL01heFdpZHRoIDk3MQ0vQXZnV2lkdGggNDI3DT4+DWVuZG9iag04IDAgb2JqDTw8DS9U
eXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjENL0Jhc2VGb250IC9UaW1lc05l
d1JvbWFuDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjUwIDMzMyA0MDgg
NTAwIDUwMCA4MzMgNzc4IDE4MCAzMzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4IA01MDAg
NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NjQgNTY0IDU2NCA0
NDQgDTkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4
ODkgNzIyIDcyMiANNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAz
MzMgMjc4IDMzMyA0NjkgNTAwIA0zMzMgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAy
NzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgDTUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3
MjIgNTAwIDUwMCA0NDQgNDgwIDIwMCA0ODAgNTQxIDc3OCANNTAwIDc3OCAzMzMgNTAwIDQ0NCAx
MDAwIDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMzMyA4ODkgNzc4IDYxMSA3NzggDTc3OCAzMzMgMzMz
IDQ0NCA0NDQgMzUwIDUwMCAxMDAwIDMzMyA5ODAgMzg5IDMzMyA3MjIgNzc4IDQ0NCA3MjIgDTI1
MCAzMzMgNTAwIDUwMCA1MDAgNTAwIDIwMCA1MDAgMzMzIDc2MCAyNzYgNTAwIDU2NCAzMzMgNzYw
IDUwMCANNDAwIDU0OSAzMDAgMzAwIDMzMyA1NzYgNDUzIDI1MCAzMzMgMzAwIDMxMCA1MDAgNzUw
IDc1MCA3NTAgNDQ0IA03MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA4ODkgNjY3IDYxMSA2MTEgNjEx
IDYxMSAzMzMgMzMzIDMzMyAzMzMgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NjQgNzIy
IDcyMiA3MjIgNzIyIDcyMiA3MjIgNTU2IDUwMCANNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNjY3
IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTAwIDUwMCA1MDAgNTAw
IDUwMCA1MDAgNTQ5IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgDV0NL0VuY29kaW5n
IC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDkgMCBSDT4+DWVuZG9iag05IDAgb2Jq
DTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1RpbWVzTmV3Um9tYW4NL0ZsYWdz
IDM0DS9Gb250QkJveCBbIC0yNTAgLTIxNiAxMTY1IDEwMDAgXQ0vTWlzc2luZ1dpZHRoIDMyMw0v
U3RlbVYgNzMNL1N0ZW1IIDczDS9JdGFsaWNBbmdsZSAwDS9DYXBIZWlnaHQgODkxDS9YSGVpZ2h0
IDQ0Ng0vQXNjZW50IDg5MQ0vRGVzY2VudCAtMjE2DS9MZWFkaW5nIDE0OQ0vTWF4V2lkdGggOTcx
DS9BdmdXaWR0aCA0MDENPj4NZW5kb2JqDTIwIDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBl
IC9UcnVlVHlwZQ0vTmFtZSAvRjINL0Jhc2VGb250IC9Db3VyaWVyTmV3DS9GaXJzdENoYXIgMzIN
L0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnRE
ZXNjcmlwdG9yIDIxIDAgUg0+Pg1lbmRvYmoNMjEgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlw
dG9yDS9Gb250TmFtZSAvQ291cmllck5ldw0vRmxhZ3MgMzQNL0ZvbnRCQm94IFsgLTI1MCAtMzAw
IDc2MiAxMDAwIF0NL01pc3NpbmdXaWR0aCA2MzUNL1N0ZW1WIDEwOQ0vU3RlbUggMTA5DS9JdGFs
aWNBbmdsZSAwDS9DYXBIZWlnaHQgODMzDS9YSGVpZ2h0IDQxNw0vQXNjZW50IDgzMw0vRGVzY2Vu
dCAtMzAwDS9MZWFkaW5nIDEzMw0vTWF4V2lkdGggNjM1DS9BdmdXaWR0aCA2MDANPj4NZW5kb2Jq
DTI0IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjMNL0Jh
c2VGb250IC9BcmlhbFVuaWNvZGVNUw0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRo
cyBbIDI3OCAyNzggMzU1IDU1NiA1NTYgODg5IDY2NyAxOTEgMzMzIDMzMyAzODkgNTg0IDI3OCAz
MzMgMjc4IDI3OCANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAy
NzggNTg0IDU4NCA1ODQgNTU2IA0xMDE1IDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIg
Mjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgNzc4IA02NjcgNzc4IDcyMiA2NjcgNjExIDcyMiA2Njcg
OTQ0IDY2NyA2NjcgNjExIDI3OCAyNzggMjc4IDQ2OSA1MDAgDTMzMyA1NTYgNTU2IDUwMCA1NTYg
NTU2IDI3OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiANNTU2IDU1NiAzMzMg
NTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAzMzQgMjYwIDMzNCA1ODQgMTAwMCANNTU2
IDEwMDAgMjIyIDI3OCAzMzMgMTAwMCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgMTAwMCAxMDAw
IDYxMSAxMDAwIA0xMDAwIDIyMiAyMjIgMzMzIDMzMyAzNTAgNTAwIDEwMDAgMzMzIDEwMDAgNTAw
IDMzMyA5NDQgMTAwMCA1MDAgNjY3IA0yNzggMzMzIDU1NiA1NTYgNTU2IDU1NiAyNjAgNTU2IDMz
MyA3MzcgMzcwIDU1NiA1ODQgMzMzIDczNyA1MDAgDTQwMCA1ODQgMzMzIDMzMyAzMzMgNTU2IDUz
NyAyNzggMzMzIDMzMyAzNjUgNTU2IDgzNCA4MzQgODM0IDYxMSANNjY3IDY2NyA2NjcgNjY3IDY2
NyA2NjcgMTAwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDI3OCAyNzggMjc4IDI3OCANNzIyIDcyMiA3
NzggNzc4IDc3OCA3NzggNzc4IDU4NCA3NzggNzIyIDcyMiA3MjIgNzIyIDY2NyA2NjcgNjExIA01
NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA4ODkgNTAwIDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDI3
OCAyNzggDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1ODQgNjExIDU1NiA1NTYgNTU2IDU1
NiA1MDAgNTU2IDUwMCANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2NyaXB0
b3IgMjUgMCBSDT4+DWVuZG9iag0yNSAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0Zv
bnROYW1lIC9BcmlhbFVuaWNvZGVNUw0vRmxhZ3MgMzINL0ZvbnRCQm94IFsgLTI1MCAtMjcxIDEy
MTcgMTA2OSBdDS9NaXNzaW5nV2lkdGggMjc4DS9TdGVtViA4MA0vU3RlbUggODANL0l0YWxpY0Fu
Z2xlIDANL0NhcEhlaWdodCAxMDY5DS9YSGVpZ2h0IDUzNQ0vQXNjZW50IDEwNjkNL0Rlc2NlbnQg
LTI3MQ0vTGVhZGluZyAzNDANL01heFdpZHRoIDEwMTQNL0F2Z1dpZHRoIDQ0MQ0+Pg1lbmRvYmoN
MjYgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GNA0vQmFz
ZUZvbnQgL0NvdXJpZXJOZXcsQm9sZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRo
cyBbIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2
MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciAyNyAwIFINPj4N
ZW5kb2JqDTI3IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0NvdXJp
ZXJOZXcsQm9sZA0vRmxhZ3MgMTY0MTgNL0ZvbnRCQm94IFsgLTI1MCAtMzAwIDcxNCAxMDAwIF0N
L01pc3NpbmdXaWR0aCA1OTUNL1N0ZW1WIDE5MQ0vU3RlbUggMTkxDS9JdGFsaWNBbmdsZSAwDS9D
YXBIZWlnaHQgODMzDS9YSGVpZ2h0IDQxNw0vQXNjZW50IDgzMw0vRGVzY2VudCAtMzAwDS9MZWFk
aW5nIDEzMw0vTWF4V2lkdGggNTk1DS9BdmdXaWR0aCA2MDANPj4NZW5kb2JqDTI5IDAgb2JqDTw8
DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjUNL0Jhc2VGb250IC9WZXJk
YW5hLEJvbGQNL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAzNDIgNDAyIDU4
NyA4NjcgNzExIDEyNzIgODYyIDMzMiA1NDMgNTQzIDcxMSA4NjcgMzYxIDQ4MCAzNjEgNjg5IA03
MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNDAyIDQwMiA4NjcgODY3IDg2
NyA2MTcgDTk2NCA3NzYgNzYyIDcyNCA4MzAgNjgzIDY1MCA4MTEgODM3IDU0NiA1NTUgNzcxIDYz
NyA5NDggODQ3IDg1MCANNzMzIDg1MCA3ODIgNzEwIDY4MiA4MTIgNzY0IDExMjggNzY0IDczNyA2
OTIgNTQzIDY4OSA1NDMgODY3IDcxMSANNzExIDY2OCA2OTkgNTg4IDY5OSA2NjQgNDIyIDY5OSA3
MTIgMzQyIDQwMyA2NzEgMzQyIDEwNTggNzEyIDY4NyANNjk5IDY5OSA0OTcgNTkzIDQ1NiA3MTIg
NjUwIDk3OSA2NjkgNjUxIDU5NyA3MTEgNTQzIDcxMSA4NjcgMTAwMCANNzExIDEwMDAgMzMyIDcx
MSA1ODcgMTA0OSA3MTEgNzExIDcxMSAxNzc3IDcxMCA1NDMgMTEzNSAxMDAwIDY5MiAxMDAwIA0x
MDAwIDMzMiAzMzIgNTg3IDU4NyA3MTEgNzExIDEwMDAgNzExIDk2NCA1OTMgNTQzIDEwNjggMTAw
MCA1OTcgNzM3IA0zNDIgNDAyIDcxMSA3MTEgNzExIDcxMSA1NDMgNzExIDcxMSA5NjQgNTk4IDg1
MCA4NjcgNDgwIDk2NCA3MTEgDTU4NyA4NjcgNTk4IDU5OCA3MTEgNzIxIDcxMSAzNjEgNzExIDU5
OCA1OTggODUwIDExODIgMTE4MiAxMTgyIDYxNyANNzc2IDc3NiA3NzYgNzc2IDc3NiA3NzYgMTA5
NCA3MjQgNjgzIDY4MyA2ODMgNjgzIDU0NiA1NDYgNTQ2IDU0NiANODMwIDg0NyA4NTAgODUwIDg1
MCA4NTAgODUwIDg2NyA4NTAgODEyIDgxMiA4MTIgODEyIDczNyA3MzUgNzEzIA02NjggNjY4IDY2
OCA2NjggNjY4IDY2OCAxMDE4IDU4OCA2NjQgNjY0IDY2NCA2NjQgMzQyIDM0MiAzNDIgMzQyIA02
NzkgNzEyIDY4NyA2ODcgNjg3IDY4NyA2ODcgODY3IDY4NyA3MTIgNzEyIDcxMiA3MTIgNjUxIDY5
OSA2NTEgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDMwIDAg
Ug0+Pg1lbmRvYmoNMzAgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAv
VmVyZGFuYSxCb2xkDS9GbGFncyAxNjQxNg0vRm9udEJCb3ggWyAtMjUwIC0yMTAgMjE0MyAxMDA1
IF0NL01pc3NpbmdXaWR0aCA1NDYNL1N0ZW1WIDE4MQ0vU3RlbUggMTgxDS9JdGFsaWNBbmdsZSAw
DS9DYXBIZWlnaHQgMTAwNQ0vWEhlaWdodCA1MDMNL0FzY2VudCAxMDA1DS9EZXNjZW50IC0yMTAN
L0xlYWRpbmcgMjE1DS9NYXhXaWR0aCAxNzg2DS9BdmdXaWR0aCA1NjgNPj4NZW5kb2JqDTMxIDAg
b2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjYNL0Jhc2VGb250
IC9WZXJkYW5hLEJvbGRJdGFsaWMNL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMg
WyAzNDIgNDAyIDU4NyA4NjcgNzExIDEyNzIgODYyIDMzMiA1NDMgNTQzIDcxMSA4NjcgMzYxIDQ4
MCAzNjEgNjg5IA03MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNzExIDcxMSA3MTEgNDAyIDQw
MiA4NjcgODY3IDg2NyA2MTcgDTk2NCA3NzYgNzYyIDcyNCA4MzAgNjgzIDY1MCA4MTEgODM3IDU0
NiA1NTUgNzcxIDYzNyA5NDggODQ3IDg1MCANNzMzIDg1MCA3ODIgNzEwIDY4MiA4MTIgNzY0IDEx
MjggNzY0IDczNyA2OTIgNTQzIDY4OSA1NDMgODY3IDcxMSANNzExIDY2OCA2OTkgNTg4IDY5OSA2
NjQgNDIyIDY5OSA3MTIgMzQyIDQwMyA2NzEgMzQyIDEwNTggNzEyIDY4NiANNjk5IDY5OSA0OTcg
NTkzIDQ1NiA3MTIgNjQ5IDk3OSA2NjkgNjUxIDU5NyA3MTEgNTQzIDcxMSA4NjcgMTAwMCANNzEx
IDEwMDAgMzMyIDcxMSA1ODcgMTA0OSA3MTEgNzExIDcxMSAxNzc3IDcxMCA1NDMgMTEzNSAxMDAw
IDY5MiAxMDAwIA0xMDAwIDMzMiAzMzIgNTg3IDU4NyA3MTEgNzExIDEwMDAgNzExIDk2NCA1OTMg
NTQzIDEwNjggMTAwMCA1OTcgNzM3IA0zNDIgNDAyIDcxMSA3MTEgNzExIDcxMSA1NDMgNzExIDcx
MSA5NjQgNTk4IDg1MCA4NjcgNDgwIDk2NCA3MTEgDTU4NyA4NjcgNTk4IDU5OCA3MTEgNzIxIDcx
MSAzNjEgNzExIDU5OCA1OTggODUwIDExODIgMTE4MiAxMTgyIDYxNyANNzc2IDc3NiA3NzYgNzc2
IDc3NiA3NzYgMTA5NCA3MjQgNjgzIDY4MyA2ODMgNjgzIDU0NiA1NDYgNTQ2IDU0NiANODMwIDg0
NyA4NTAgODUwIDg1MCA4NTAgODUwIDg2NyA4NTAgODEyIDgxMiA4MTIgODEyIDczNyA3MzUgNzEz
IA02NjggNjY4IDY2OCA2NjggNjY4IDY2OCAxMDE4IDU4OCA2NjQgNjY0IDY2NCA2NjQgMzQyIDM0
MiAzNDIgMzQyIA02NzkgNzEyIDY4NiA2ODYgNjg2IDY4NiA2ODYgODY3IDY4NiA3MTIgNzEyIDcx
MiA3MTIgNjUxIDY5OSA2NTEgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNj
cmlwdG9yIDMyIDAgUg0+Pg1lbmRvYmoNMzIgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9y
DS9Gb250TmFtZSAvVmVyZGFuYSxCb2xkSXRhbGljDS9GbGFncyAxNjQ4MA0vRm9udEJCb3ggWyAt
MjUwIC0yMTAgMjE0MyAxMDA1IF0NL01pc3NpbmdXaWR0aCA1NDYNL1N0ZW1WIDE4MQ0vU3RlbUgg
MTgxDS9JdGFsaWNBbmdsZSAtMTENL0NhcEhlaWdodCAxMDA1DS9YSGVpZ2h0IDUwMw0vQXNjZW50
IDEwMDUNL0Rlc2NlbnQgLTIxMA0vTGVhZGluZyAyMTUNL01heFdpZHRoIDE3ODYNL0F2Z1dpZHRo
IDU2OA0+Pg1lbmRvYmoNMzUgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBl
DS9OYW1lIC9GNw0vQmFzZUZvbnQgL1ZlcmRhbmENL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1
DS9XaWR0aHMgWyAzNTIgMzk0IDQ1OSA4MTggNjM2IDEwNzYgNzI3IDI2OSA0NTQgNDU0IDYzNiA4
MTggMzY0IDQ1NCAzNjQgNDU0IA02MzYgNjM2IDYzNiA2MzYgNjM2IDYzNiA2MzYgNjM2IDYzNiA2
MzYgNDU0IDQ1NCA4MTggODE4IDgxOCA1NDUgDTEwMDAgNjg0IDY4NiA2OTggNzcxIDYzMiA1NzUg
Nzc1IDc1MSA0MjEgNDU1IDY5MyA1NTcgODQzIDc0OCA3ODcgDTYwMyA3ODcgNjk1IDY4NCA2MTYg
NzMyIDY4NCA5ODkgNjg1IDYxNSA2ODUgNDU0IDQ1NCA0NTQgODE4IDYzNiANNjM2IDYwMSA2MjMg
NTIxIDYyMyA1OTYgMzUyIDYyMyA2MzMgMjc0IDM0NCA1OTIgMjc0IDk3MyA2MzMgNjA3IA02MjMg
NjIzIDQyNyA1MjEgMzk0IDYzMyA1OTIgODE4IDU5MiA1OTIgNTI1IDYzNSA0NTQgNjM1IDgxOCAx
MDAwIA02MzYgMTAwMCAyNjkgNjM2IDQ1OSA4MTggNjM2IDYzNiA2MzYgMTUyMSA2ODQgNDU0IDEw
NzAgMTAwMCA2ODUgMTAwMCANMTAwMCAyNjkgMjY5IDQ1OSA0NTkgNTQ1IDYzNiAxMDAwIDYzNiA5
NzcgNTIxIDQ1NCA5ODEgMTAwMCA1MjUgNjE1IA0zNTIgMzk0IDYzNiA2MzYgNjM2IDYzNiA0NTQg
NjM2IDYzNiAxMDAwIDU0NSA2NDUgODE4IDQ1NCAxMDAwIDYzNiANNTQyIDgxOCA1NDIgNTQyIDYz
NiA2NDIgNjM2IDM2NCA2MzYgNTQyIDU0NSA2NDUgMTAwMCAxMDAwIDEwMDAgNTQ1IA02ODQgNjg0
IDY4NCA2ODQgNjg0IDY4NCA5ODQgNjk4IDYzMiA2MzIgNjMyIDYzMiA0MjEgNDIxIDQyMSA0MjEg
DTc3NSA3NDggNzg3IDc4NyA3ODcgNzg3IDc4NyA4MTggNzg3IDczMiA3MzIgNzMyIDczMiA2MTUg
NjA1IDYyMCANNjAxIDYwMSA2MDEgNjAxIDYwMSA2MDEgOTU1IDUyMSA1OTYgNTk2IDU5NiA1OTYg
Mjc0IDI3NCAyNzQgMjc0IA02MTIgNjMzIDYwNyA2MDcgNjA3IDYwNyA2MDcgODE4IDYwNyA2MzMg
NjMzIDYzMyA2MzMgNTkyIDYyMyA1OTIgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0Zv
bnREZXNjcmlwdG9yIDM2IDAgUg0+Pg1lbmRvYmoNMzYgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNj
cmlwdG9yDS9Gb250TmFtZSAvVmVyZGFuYQ0vRmxhZ3MgMzINL0ZvbnRCQm94IFsgLTI1MCAtMjEw
IDE4MzQgMTAwNSBdDS9NaXNzaW5nV2lkdGggNDU2DS9TdGVtViA5Mg0vU3RlbUggOTINL0l0YWxp
Y0FuZ2xlIDANL0NhcEhlaWdodCAxMDA1DS9YSGVpZ2h0IDUwMw0vQXNjZW50IDEwMDUNL0Rlc2Nl
bnQgLTIxMA0vTGVhZGluZyAyMTUNL01heFdpZHRoIDE1MjgNL0F2Z1dpZHRoIDUwOA0+Pg1lbmRv
YmoNMiAwIG9iag1bIC9QREYgL1RleHQgL0ltYWdlQyAgXQ1lbmRvYmoNNSAwIG9iag08PA0vS2lk
cyBbNCAwIFIgMTIgMCBSIDE5IDAgUiAyOCAwIFIgMzggMCBSIDQyIDAgUiBdDS9Db3VudCA2DS9U
eXBlIC9QYWdlcw0vUGFyZW50IDUyIDAgUg0+Pg1lbmRvYmoNNDYgMCBvYmoNPDwNL0tpZHMgWzQ1
IDAgUiA0OSAwIFIgXQ0vQ291bnQgMg0vVHlwZSAvUGFnZXMNL1BhcmVudCA1MiAwIFINPj4NZW5k
b2JqDTUyIDAgb2JqDTw8DS9LaWRzIFs1IDAgUiA0NiAwIFIgXQ0vQ291bnQgOA0vVHlwZSAvUGFn
ZXMNL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXQ0+Pg1lbmRvYmoNMSAwIG9iag08PA0vQ3JlYXRv
ciA8RkVGRjAwNDEwMDIwMDA0RTAwNEYwMDU0MDA0NTAwMjAwMDRGMDA0RTAwMjAwMDQxMDAyMDAw
NTAwMDRGMDA1MzAwNTMwMDQ5MDA0MjAwNEMwMDQ1MDAyMDAwNDUwMDU4MDA1NDAwNDUwMDRFMDA1
MzAwNDkwMDRGMDA0RTAwMjAwMDU0MDA0RjAwMjAwMDUzMDA0OTAwNDEwMDUwMDAyMDAwMjgwMDUw
MDA3MjAwNjUwMDc2MDA2OTAwNjUwMDc3MDAyOTAwMjAwMDJEMDAyMDAwNEQwMDY5MDA2MzAwNzIw
MDZGMDA3MzAwNkYwMDY2MDA3NDAwMjAwMDU3MDA2RjAwNzIwMDY0Pg0vQ3JlYXRpb25EYXRlIChE
OjIwMDQwNDA2MTUyNjQ3KQ0vVGl0bGUgPEZFRkYwMDQxMDAyMDAwNEUwMDRGMDA1NDAwNDUwMDIw
MDA0RjAwNEUwMDIwMDA0MTAwMjAwMDUwMDA0RjAwNTMwMDUzMDA0OTAwNDIwMDRDMDA0NTAwMjAw
MDQ1MDA1ODAwNTQwMDQ1MDA0RTAwNTMwMDQ5MDA0RjAwNEUwMDIwMDA1NDAwNEYwMDIwMDA1MzAw
NDkwMDQxMDA1MDAwMkUwMDY0MDA2RjAwNjM+DS9BdXRob3IgPEZFRkYwMDcwMDA2RjAwNzMwMDc1
MDA2RTAwNjE+DS9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIgNS4wIGZvciBXaW5kb3dzIE5U
KQ0+Pg1lbmRvYmoNMyAwIG9iag08PA0vUGFnZXMgNTIgMCBSDS9UeXBlIC9DYXRhbG9nDT4+DWVu
ZG9iag14cmVmDTAgNTMNMDAwMDAwMDAwMCA2NTUzNSBmIA0wMDAwMDUzMzM0IDAwMDAwIG4gDTAw
MDAwNTMwMTMgMDAwMDAgbiANMDAwMDA1MzkzNCAwMDAwMCBuIA0wMDAwMDAxNzg3IDAwMDAwIG4g
DTAwMDAwNTMwNTIgMDAwMDAgbiANMDAwMDA0MjEwOSAwMDAwMCBuIA0wMDAwMDQzMjA4IDAwMDAw
IG4gDTAwMDAwNDM0NzggMDAwMDAgbiANMDAwMDA0NDU2NyAwMDAwMCBuIA0wMDAwMDAwMDE5IDAw
MDAwIG4gDTAwMDAwMDE3NjYgMDAwMDAgbiANMDAwMDAyNjMwMiAwMDAwMCBuIA0wMDAwMDAyMDYw
IDAwMDAwIG4gDTAwMDAwMjUzOTAgMDAwMDAgbiANMDAwMDAwMTkxNyAwMDAwMCBuIA0wMDAwMDAy
MDQxIDAwMDAwIG4gDTAwMDAwMjU0MTIgMDAwMDAgbiANMDAwMDAyNjI4MiAwMDAwMCBuIA0wMDAw
MDI3OTk1IDAwMDAwIG4gDTAwMDAwNDQ4MjcgMDAwMDAgbiANMDAwMDA0NTkxMiAwMDAwMCBuIA0w
MDAwMDI2NDYyIDAwMDAwIG4gDTAwMDAwMjc5NzQgMDAwMDAgbiANMDAwMDA0NjE3MSAwMDAwMCBu
IA0wMDAwMDQ3MjczIDAwMDAwIG4gDTAwMDAwNDc1MzggMDAwMDAgbiANMDAwMDA0ODYyOCAwMDAw
MCBuIA0wMDAwMDMwOTE3IDAwMDAwIG4gDTAwMDAwNDg4OTUgMDAwMDAgbiANMDAwMDA1MDAwMSAw
MDAwMCBuIA0wMDAwMDUwMjY5IDAwMDAwIG4gDTAwMDAwNTEzODEgMDAwMDAgbiANMDAwMDAyODE1
MSAwMDAwMCBuIA0wMDAwMDMwODk2IDAwMDAwIG4gDTAwMDAwNTE2NTcgMDAwMDAgbiANMDAwMDA1
Mjc1NSAwMDAwMCBuIA0wMDAwMDMxMDI3IDAwMDAwIG4gDTAwMDAwMzU2NDcgMDAwMDAgbiANMDAw
MDAzMTEyNCAwMDAwMCBuIA0wMDAwMDM1NjI2IDAwMDAwIG4gDTAwMDAwMzU3NTcgMDAwMDAgbiAN
MDAwMDAzOTAxOCAwMDAwMCBuIA0wMDAwMDM1ODQzIDAwMDAwIG4gDTAwMDAwMzg5OTcgMDAwMDAg
biANMDAwMDAzOTk2MSAwMDAwMCBuIA0wMDAwMDUzMTYwIDAwMDAwIG4gDTAwMDAwMzkxNzQgMDAw
MDAgbiANMDAwMDAzOTk0MSAwMDAwMCBuIA0wMDAwMDQxOTc3IDAwMDAwIG4gDTAwMDAwNDAwOTQg
MDAwMDAgbiANMDAwMDA0MTk1NiAwMDAwMCBuIA0wMDAwMDUzMjQyIDAwMDAwIG4gDXRyYWlsZXIN
PDwNL1NpemUgNTMNL1Jvb3QgMyAwIFINL0luZm8gMSAwIFINL0lEIFs8YmYwYzNmYWVlOGY4YWU1
MWFhYzZiOTUwODAzOTZhMmM+PGJmMGMzZmFlZThmOGFlNTFhYWM2Yjk1MDgwMzk2YTJjPl0NPj4N
c3RhcnR4cmVmDTUzOTg0DSUlRU9GDQ==

--Multipart_Mon__12_Apr_2004_10:41:59_+0200_005aafd8--

From owner-dal@eso.org  Tue Apr 13 15:32:50 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDWSCi018829
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 13 Apr 2004 15:32:28 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3DDWSlV018827
	for dal-outgoing; Tue, 13 Apr 2004 15:32:28 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDWKCi018803;
	Tue, 13 Apr 2004 15:32:20 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3DDWITY017778;
	Tue, 13 Apr 2004 15:32:19 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3DDWHUI052918
          ; Tue, 13 Apr 2004 15:32:18 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id PAA24147;
	Tue, 13 Apr 2004 15:27:49 +0200 (MET DST)
Date: Tue, 13 Apr 2004 15:27:49 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404131327.PAA24147@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: Data Model serialisation in VOTable
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear Dal and DM colleagues,
   M.Louys and I just completed an IVOA note on rules we
propose to use to serialise a Data Model in VOTable.
   This is a contribution to the discussion on Data Model
serialisation/ Votable interface  planned for the following
weeks.

   Status: it is an IVOA Note.

   Today you can find it there:
   http://alinda.u-strasbg.fr/ModelVOTSer.pdf

   Hope to have this on the IVOA note later today.


   Another note (by T.Boch, P.Fernique, M.louys, A.Micol and I) 
which is a proposal for SIA evolution is to be released also today.

Regards
François



SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Tue Apr 13 15:50:50 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDoYCi020965
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 13 Apr 2004 15:50:34 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3DDoYkk020964
	for dal-outgoing; Tue, 13 Apr 2004 15:50:34 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDoSCi020952;
	Tue, 13 Apr 2004 15:50:29 +0200 (MEST)
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3DDoRTY018677;
	Tue, 13 Apr 2004 15:50:27 +0200 (CEST)
Received: from roe.ac.uk (81-86-95-43.dsl.pipex.com [81.86.95.43])
	by colossus.systems.pipex.net (Postfix) with ESMTP id C4B6D1C000B9;
	Tue, 13 Apr 2004 14:50:25 +0100 (BST)
Message-ID: <407BEFD4.2090903@roe.ac.uk>
Date: Tue, 13 Apr 2004 14:49:08 +0100
From: "Martin @ ROE" <mch@roe.ac.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: Data Model serialisation in VOTable
References: <200404131327.PAA24147@alinda.u-strasbg.fr>
In-Reply-To: <200404131327.PAA24147@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Martin @ ROE" <mch@roe.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Returning to my favourite subject:

Why are we trying to serialise data models to VOTable?  There are 
already industry standard mechanisms for serialising object models to 
XML. Trying to use a VO-specific table format to represent general data 
models sounds like an interesting computer science problem, but not 
something that will help takeup or interoperability of VO services.

Deriving a new schema that describes the XML/model is the right way to 
go, not forcing new models into inapropriate schemas just because we 
happen to have one lying around.  Not all problems can (or should) be 
solved using the same spanner.

Or have I got the wrong end of the stick here?

Regards,

Martin

Francois Bonnarel wrote:

> Dear Dal and DM colleagues,
>    M.Louys and I just completed an IVOA note on rules we
> propose to use to serialise a Data Model in VOTable.
>    This is a contribution to the discussion on Data Model
> serialisation/ Votable interface  planned for the following
> weeks.
> 
>    Status: it is an IVOA Note.
> 
>    Today you can find it there:
>    http://alinda.u-strasbg.fr/ModelVOTSer.pdf
> 
>    Hope to have this on the IVOA note later today.
> 
> 
>    Another note (by T.Boch, P.Fernique, M.louys, A.Micol and I) 
> which is a proposal for SIA evolution is to be released also today.
> 
> Regards
> François
> 
> 
> 
> SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>
> 
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
> 
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
> ---------------------------------------------------------------------
> 


-- 
Martin Hill
Software Engineer, AstroGrid (ROE)
07901 55 24 66

From owner-dal@eso.org  Tue Apr 13 15:57:45 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDvUCi021934
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 13 Apr 2004 15:57:30 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3DDvUv2021933
	for dal-outgoing; Tue, 13 Apr 2004 15:57:30 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDvOCi021920;
	Tue, 13 Apr 2004 15:57:24 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3DDvMXe005531;
	Tue, 13 Apr 2004 15:57:23 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3DDvMUI073923
          ; Tue, 13 Apr 2004 15:57:22 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id PAA25832;
	Tue, 13 Apr 2004 15:52:54 +0200 (MET DST)
Date: Tue, 13 Apr 2004 15:52:54 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404131352.PAA25832@alinda.u-strasbg.fr>
To: mch@roe.ac.uk
Subject: Re: Data Model serialisation in VOTable
Cc: dal@ivoa.net, dm@ivoa.net
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Martin

The only purpose of this note is to show that we CAN use VOTable
for serialisation not that We MUST !!!
And if we CAN sometimes, it may be usefull to some people around
there.

   But this topic is also related to the SIAP generalization one
as you will see in a couple of hours.

Regards
François
SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Tue Apr 13 15:59:31 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDxDCi022154
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 13 Apr 2004 15:59:14 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3DDxDR4022153
	for dal-outgoing; Tue, 13 Apr 2004 15:59:13 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DDx8Ci022141;
	Tue, 13 Apr 2004 15:59:08 +0200 (MEST)
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3DDx6TY019119;
	Tue, 13 Apr 2004 15:59:06 +0200 (CEST)
Received: from dial.pipex.com (81-86-95-43.dsl.pipex.com [81.86.95.43])
	by colossus.systems.pipex.net (Postfix) with ESMTP id 0F5CC1C00189;
	Tue, 13 Apr 2004 14:59:04 +0100 (BST)
Message-ID: <407BF1DB.2050200@dial.pipex.com>
Date: Tue, 13 Apr 2004 14:57:47 +0100
From: Martin Hill <mchill@dial.pipex.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Cc: mch@roe.ac.uk, dal@ivoa.net, dm@ivoa.net
Subject: Re: Data Model serialisation in VOTable
References: <200404131352.PAA25832@alinda.u-strasbg.fr>
In-Reply-To: <200404131352.PAA25832@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Martin Hill <mchill@dial.pipex.com>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Excellent, thanks Francois.  Looking forward to the SIAP one...

Francois Bonnarel wrote:

> Hi Martin
> 
> The only purpose of this note is to show that we CAN use VOTable
> for serialisation not that We MUST !!!
> And if we CAN sometimes, it may be usefull to some people around
> there.
> 
>    But this topic is also related to the SIAP generalization one
> as you will see in a couple of hours.
> 
> Regards
> François
> SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>
> 
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
> 
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
> ---------------------------------------------------------------------
> 

From owner-dm@eso.org  Wed Apr 14 00:55:45 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DMtHYm018870
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 14 Apr 2004 00:55:17 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3DMtHcd018869
	for dm-outgoing; Wed, 14 Apr 2004 00:55:17 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3DMtEYm018863;
	Wed, 14 Apr 2004 00:55:14 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3DMtBXe027241;
	Wed, 14 Apr 2004 00:55:13 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3DMtAUI071355
          ; Wed, 14 Apr 2004 00:55:10 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id AAA00398;
	Wed, 14 Apr 2004 00:50:41 +0200 (MET DST)
Date: Wed, 14 Apr 2004 00:50:41 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404132250.AAA00398@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: SIA Evolution proposal
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear DM and DAL partners,
    You can now find the Note I annouced sooner today
which is a proposal for a SIA evolution towards more structured features

   at this  addres: http://alinda.u-strasbg.fr/SiaEvol.rtf

  A formal IVOA version will be posted tommorrow.

   A few preliminary remarks about that:

     - Yesterday Pedro and Jesus posted  a proposal naamed
"A note on a possible extension to SIAP" on the DAL.
        Their note, the current note and the previous note I posted today with
    Mireille are contributions to a debate we would like to have in the IVOA
    about structuring DAL outputs benefiting from the Data Model efforts
    and without erasing all that has been done under the name SIA (or SSA)
    in the previous monthes.

    -    We have been in close contact with Pedro and Jesus in the last
    weeks and discussed a lot this topic. Due to various reasons
    we decided together to post separate notes eventually, as a
    starting point to a more open discussion.

    - The note posted now is based on the IDHA data model. We will
probably adapt this to the IVOA Observation Data Model before Boston.

Regards
François
SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dm@eso.org  Wed Apr 14 11:12:37 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3E9C7Ym002420
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 14 Apr 2004 11:12:07 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3E9C7BO002419
	for dm-outgoing; Wed, 14 Apr 2004 11:12:07 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3E9C2Ym002407;
	Wed, 14 Apr 2004 11:12:03 +0200 (MEST)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3E9C1Xe013449;
	Wed, 14 Apr 2004 11:12:01 +0200 (CEST)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1BDgR6-000IKo-QB; Wed, 14 Apr 2004 10:12:00 +0100
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1BDgR6-0003uh-00; Wed, 14 Apr 2004 10:12:00 +0100
Date: Wed, 14 Apr 2004 10:12:00 +0100 (BST)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: SIA Evolution proposal
In-Reply-To: <200404132250.AAA00398@alinda.u-strasbg.fr>
Message-ID: <Pine.GSO.4.53.0404141011000.5248@adikia>
References: <200404132250.AAA00398@alinda.u-strasbg.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BDgR6-000IKo-QB*BtD6F5piTYo*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mercury.hq.eso.org id i3E9C6Ym002416
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


I hate to be awkward, but in AstroGrid we decided some time ago that
documents should be posted in a non-platform-specific format e.g. html or
pdf....

thanks

cheers

a
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).


On Wed, 14 Apr 2004, Francois Bonnarel wrote:

> Dear DM and DAL partners,
>     You can now find the Note I annouced sooner today
> which is a proposal for a SIA evolution towards more structured features
>
>    at this  addres: http://alinda.u-strasbg.fr/SiaEvol.rtf
>
>   A formal IVOA version will be posted tommorrow.
>
>    A few preliminary remarks about that:
>
>      - Yesterday Pedro and Jesus posted  a proposal naamed
> "A note on a possible extension to SIAP" on the DAL.
>         Their note, the current note and the previous note I posted today with
>     Mireille are contributions to a debate we would like to have in the IVOA
>     about structuring DAL outputs benefiting from the Data Model efforts
>     and without erasing all that has been done under the name SIA (or SSA)
>     in the previous monthes.
>
>     -    We have been in close contact with Pedro and Jesus in the last
>     weeks and discussed a lot this topic. Due to various reasons
>     we decided together to post separate notes eventually, as a
>     starting point to a more open discussion.
>
>     - The note posted now is based on the IDHA data model. We will
> probably adapt this to the IVOA Observation Data Model before Boston.
>
> Regards
> François
> SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>
>
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
>
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
> ---------------------------------------------------------------------
>

From owner-dm@eso.org  Wed Apr 14 12:35:04 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3EAYlYm011143
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 14 Apr 2004 12:34:48 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3EAYl05011142
	for dm-outgoing; Wed, 14 Apr 2004 12:34:47 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3EAYjYm011136;
	Wed, 14 Apr 2004 12:34:45 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3EAYhXe015610;
	Wed, 14 Apr 2004 12:34:43 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3EAYhUI050835
          ; Wed, 14 Apr 2004 12:34:43 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id MAA12540;
	Wed, 14 Apr 2004 12:30:13 +0200 (MET DST)
Date: Wed, 14 Apr 2004 12:30:13 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404141030.MAA12540@alinda.u-strasbg.fr>
To: amsr@jb.man.ac.uk
Subject: Re: SIA Evolution proposal
Cc: dal@ivoa.net, dm@ivoa.net
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Anita and others,
   You can now finf the two notes in pdf format at these
URL:

   http://alinda.uu-strasbg.fr/ModelVOTSer.pdf
and 
   http://alinda.u-strasbg.fr/SiapEvolution.pdf

Regards
François
SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Wed Apr 14 19:49:21 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3EHn4HK028440
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 14 Apr 2004 19:49:04 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3EHn4pc028439
	for dal-outgoing; Wed, 14 Apr 2004 19:49:04 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3EHn1HK028429
	for <dal@ivoa.net>; Wed, 14 Apr 2004 19:49:01 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3EHmxXe014861
	for <dal@ivoa.net>; Wed, 14 Apr 2004 19:48:59 +0200 (CEST)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i3EHmtc26826
	for <dal@ivoa.net>; Wed, 14 Apr 2004 11:48:55 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i3EHmrTU014910;
	Wed, 14 Apr 2004 11:48:54 -0600 (MDT)
Date: Wed, 14 Apr 2004 11:48:53 -0600 (MDT)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net
Subject: Data representation using VOTable, FITS, XML etc.
Message-ID: <Pine.LNX.4.44.0404141148130.3303-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.4, required 7,
	BAYES_01 -5.40, USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000



---------- Forwarded message ----------
Date: Wed, 14 Apr 2004 11:46:34 -0600 (MDT)
From: Doug Tody <dtody@zia.aoc.nrao.edu>
To: VOTable@ivoa.net
Subject: Re: Comments on V1.1 - Future of VOTable (flame bait sigh)

Didn't we just have this same discussion a while back?

There are some significant advantages to a generic table mechanism.

    o	By definition a generic table mechanism should work well for storing
	tabular data.  General table management software can be written to
	implement the table abstraction, then this software can be reused
	throughout a data analysis system.  Having factored off the table
	abstraction as common software it is worthwhile investing effort
	in such software, e.g., to efficiently handle bulk data.

    o	Data stored in a general can be manipulated with generic table
	tools.	This has been very successful in the past with FITS tables
	and we are seeing it again now with VOTable.

    o	Compatibility with existing astronomical software, much of which
	is table-based.  As Clive mentions, it is easy to modify such
	software to read VOTable as well as FITS ascii and binary table,
	text tables, etc.  Integration of VO and legacy astronomical formats
	such as FITS binary datable is much easier if both implement the
	table abstraction.

    o	Compatibility with non-astronomical software which is also table
    	based, e.g., databases, spreadsheets, statistical analysis tools.

    o	Any approach which uses a general container mechanism is likely
	to be more open than one which uses a custom schema designed for a
	single class of data.  One can represent the core elements of the
	data model in the container, and extract them from the container
	later to manipulate the object in class-specific code.	But other
	information can be stored in the generic container as well.
	This flexibility is important to allow data representation to
	evolve, or to adapt to subclasses of data.

If all one wants to do is serialize a single data model in XML then I
agree the simplest thing to do is to define a custom schema specifically
for that data model.  While simple, this is very restrictive.  Anything
which does not fit into the predefined schema is either disallowed, or
awkward to handle via the schema approach.  As soon as we try to model
complex datasets by aggregating multiple component data models (as we do
in the real world all the time) then the schema-based approach starts to
break down.  In general the schema approach only works at the level of
individual, well defined data models.

Perhaps we should try both approaches.  Any tabular data, be it a catalog
or a 1D spectrum, can be reasonably expressed using a generic table
mechanism, permitting use of generic tools and providing scalability to
very large datasets.  For any self-contained, well defined data model
it is natural to define an XML schema.  In cases where the data model
is simple enough we can implement a Web service which is schema-based.
More complex cases are probably better addressed using a generic,
flexible/open document-centric approach such as VOTable or FITS.

	- Doug


From owner-dal@eso.org  Thu Apr 15 13:28:10 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3FBRnn0011288
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 15 Apr 2004 13:27:49 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3FBRmS9011286
	for dal-outgoing; Thu, 15 Apr 2004 13:27:48 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3FBRgn0011270;
	Thu, 15 Apr 2004 13:27:42 +0200 (MEST)
Received: from eso.org (st14.hq.eso.org [134.171.10.25])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i3FBRgs28919;
	Thu, 15 Apr 2004 13:27:42 +0200 (MEST)
Message-ID: <407E71AE.7000405@eso.org>
Date: Thu, 15 Apr 2004 13:27:42 +0200
From: Alberto Micol <Alberto.Micol@eso.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dal@ivoa.net, dm@ivoa.net
Subject: Re: SIA Evolution proposal
References: <200404132250.AAA00398@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Just a very brief summary,  a question to Pedro and Jesus (VILSPA),
and, for "par condicio", a question to Thomas, Francois and Mireille (CDS),
on the SIA evolution proposals:

http://www.ivoa.net/forum/dal/0145.htm (VILSPA)
http://www.ivoa.net/forum/dal/0150.htm (CDS)

Both proposals manifest the same requirement: the need
to provide enhanced metadata to a user of a S?A service (being it a SIA, 
SSA, etc).

The different is in the implementation, whereby:

 - VILSPA uses VOTable "nested tables"

 - CDS, which used VOTable "nested resources" in a previous version,
   in the last proposal simply uses a second GeneralFeatures resource
   parallel to the "main" resource (the one containing the S?A results).
   Such resource contains as many tables as needed to describe properties
   that otherwise would get repeated (eg filter descriptions, telescope 
location, etc).
   Very much like one would design his/her relational database.

   NOTE: In the CDS document that processed is labeled "factorisation",
   which is probably coming from some french translation, I would call 
it "normalization"
   (from the relational word), but I'm italian ...

The VILSPA proposal will require a modification of the VOTable schema
to allow TABLE as a possible datatype for a FIELD element.

CDS does not require any change, and indeed is already used by various 
data providers.

What is not clear to me, in the VILSPA proposal, how to avoid 
unnecessary repetitions.
The example by Pedro and Jesus shows a single record; but suppose that 
multiple records
(say 4) are returned, and suppose that 2 observations were taken in 
energy band A and
2 observations were taken in energy band B. The same Energy_Band_Table 
will be
seen in two different records for both the A filter and the B cases.

In the CDS case that is done by putting all the Energy_Band (filter in 
the cds case) definitions
into a single filter table in the GeneralFeatures resource, and by 
referring to it.
(btw, the link should not be done on the filtername, but on a filter 
identifier instead,
since the same filter name could be used by two different instruments 
(see F555W for
both WFPC2 and ACS)).

Pedro or Jesus, could you please clarify that?


What is also not clear is how, with the new proposed CDS structure, one
could describe multiple members of observations. In the previous IDHA 
version
that was achieved with "nested resources"; but now?

Francois et al., could you please clarify that?


A side comment more for the VOTable WG:
 I like the capability of nesting tables; that would allow a one to one 
mapping between
some special FITS file and VOTable. The HST/STIS  extracted spectra are 
organised
in nested tables (a table cell contains a spectrum) indeed!

Thanks,

Alberto


From owner-dm@eso.org  Fri Apr 16 12:30:57 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GASsTk022938
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 12:28:54 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GASsek022937
	for dm-outgoing; Fri, 16 Apr 2004 12:28:54 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GASoTk022929;
	Fri, 16 Apr 2004 12:28:51 +0200 (MEST)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3GASiXe027874;
	Fri, 16 Apr 2004 12:28:44 +0200 (CEST)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3GASaog008503;
	Fri, 16 Apr 2004 12:28:36 +0200 (MET DST)
Received: from isol03.vilspa.esa.int (isol03.vilspa.esa.int [193.147.153.17])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i3GA63u3018863;
	Fri, 16 Apr 2004 12:06:03 +0200 (MEST)
Subject: Re: Re: SIA Evolution Proposal
From: Pedro Osuna <posuna@iso.vilspa.esa.es>
To: Alberto.Micol@eso.org
Cc: dal@ivoa.net, dm@ivoa.net
Content-Type: text/plain
Message-Id: <1082109962.19991.56.camel@isol03.vilspa.esa.int>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) 
Date: Fri, 16 Apr 2004 12:06:03 +0200
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Pedro Osuna <posuna@iso.vilspa.esa.es>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Alberto, dear all

thanks for your thorough comments on our note. Please find bellow our
explanation to your concern. We hope it helps a bit.


The main goal of our proposal is to be able to add structure to the
results of a SIAP query.

In our view, the CDS proposal using the current DTD allows for the
inclusion of several "parallel" <RESOURCE> elements with metadata
descriptions, but in the end does not solve the "structurization"
problem, as the results keep on being somehow flat. Parallel (i.e., same
level) <RESOURCE>s can not allow for structure inside. The CDS proposal
gives a <RESOURCE> of type "Results" and several others at the same
level. This is due to the fact that to allow for the inclusion of real
data inside the resource (i.e., to allow for structure), the resource's
TABLE _should_ allow to include inside it another RESOURCE (or another
TABLE, as we propose). 
This, however, can not currently be done, as -according to the current
DTD-  neither the TABLE element nor the FIELD one allow for either
TABLES or RESOURCES.


We would therefore have two options to solve the problem:
- modify the DTD to allow RESOURCEs inside TABLEs
- modify the DTD to allow TABLEs inside TABLEs

The first one, we dislike as we believe it would introduce redundancy: a
resource contains a lot of header information and descriptions; the same
resource header will appear in every row hence producing redundancy.

The second option, that we proposed, is to enable the inclussion
of tables inside tables. This option can be summarized
as ONE "results" <RESOURCE> whose <TABLE> might contain nested tables
inside. The nested tables contain the minimal information needed for the
representation, and it would be backwards compatible with the current
Sia protocol if the client would only take the first level (i.e. a flat
table. (On the other hand, additional metadata information could be
added in other resources, following the CDS approach).

You said:
[...]
The example by Pedro and Jesus shows a single record; but suppose that
multiple records (say 4) are returned, and suppose that 2 observations
were taken in energy band A and 2 observations were taken in energy band
B. The same Energy_Band_Table will be seen in two different records for
both the A filter and the B cases.
[...]

Even when one filter appears in more than one "observation", the
energyband table is not the same one. The energyband table contained in
every observation row is the table which contains the different images
for different filters for this observation. As the image for filter A
for obs 0011020 is different than the image for filter A for obs 0011021
there is no redundancy. As we said, the description of filter A could
appear in a separate filters resource, but not in the results resource
itself.

Following your example, and using a tree representation and a "pseudo
xml/votable format" representation:
<results type resource>
 <observation table>
  <tr>
    <td>obs1 Image</td>
    <td>
       <filter table for obs1>
         <tr> obs1 Filter A image </tr>
         <tr> obs1 Filter B image </tr>
        </filter table for obs1>
      </td>
  </tr>

  <tr>
     <td>obs2 Image</td>
     <td>
       <filter table for obs2>
         <tr> obs2 Filter A image </tr>
         <tr> obs2 Filter B image </tr>
       </filter table for obs2>
     </td>
   </tr>
 </observation table>
</results type resource>

(i,e., something like:)
results _______ obs 1_______ Filter A             
         |                  |_____ Filter B      
         |_______ obs 2_______ Filter A                 
                            |_____ Filter B

As you can see, there is no inherent redundancy in this approach. The
redundancy might appear in the client display, for which the following
question might appear:

How does the client "group" (and this is the key word we believe) the
information coming from different projects, if we do not know _what_
each of the resource tables inside it is describing?

The answer to this is in the UCDs. Every table field information should
be described by a proper UCD. In the case of our energy bands, we ought
to find a proper UCD that would describe the _type_ of information
contained in that table (i.e., in the "sub-structure" of our SIAP
result. The clients should then, in our view, group things by the _type_
of quantity they describe in their UCD, rather than by their name (which
would imply _what_ they are instead of what _type_ they are).

By doing this, clients could group results in a different hierarchy than
the original one in the Data Provider data model, and this would not
have any problem, as -in the end- the image is what is important for the
SIAP, and whether it is at the first level or third in the original
hierarchy is of no importance to the user that just wants to be able to
compare things of the same type.

We hope this clarifies our view a little bit more, and wait for your
hopefully not too discouraging comments.

Best regards,
Pedro & Jesus

From owner-dal@eso.org  Fri Apr 16 13:02:51 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GB2aTk025464
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 13:02:36 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GB2aoK025463
	for dal-outgoing; Fri, 16 Apr 2004 13:02:36 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GB2PTk025430;
	Fri, 16 Apr 2004 13:02:25 +0200 (MEST)
Received: from eso.org (st14.hq.eso.org [134.171.10.25])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i3GB2Os26894;
	Fri, 16 Apr 2004 13:02:24 +0200 (MEST)
Message-ID: <407FBD40.6040900@eso.org>
Date: Fri, 16 Apr 2004 13:02:24 +0200
From: Alberto Micol <Alberto.Micol@eso.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pedro Osuna <posuna@iso.vilspa.esa.es>
CC: dal@ivoa.net, dm@ivoa.net
Subject: Re: SIA Evolution Proposal
References: <1082109962.19991.56.camel@isol03.vilspa.esa.int>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Dear Pedro,

>In our view, the CDS proposal using the current DTD allows for the
>inclusion of several "parallel" <RESOURCE> elements with metadata
>descriptions, but in the end does not solve the "structurization"
>problem, as the results keep on being somehow flat. Parallel (i.e., same
>level) <RESOURCE>s can not allow for structure inside. The CDS proposal
>gives a <RESOURCE> of type "Results" and several others at the same
>level. This is due to the fact that to allow for the inclusion of real
>data inside the resource (i.e., to allow for structure), the resource's
>TABLE _should_ allow to include inside it another RESOURCE (or another
>TABLE, as we propose).

As said, the previous CDS proposal included nested resources
and that allowed more structure. I hope Francois will comment on that.

But have you considered such option of nesting resourcing instead of tables?
I find that cleaner ...


>> Alberto wrote:
>>
>>The example by Pedro and Jesus shows a single record; but suppose that
>>multiple records (say 4) are returned, and suppose that 2 observations
>>were taken in energy band A and 2 observations were taken in energy band
>>B. The same Energy_Band_Table will be seen in two different records for
>>both the A filter and the B cases.
>
>Even when one filter appears in more than one "observation", the
>energyband table is not the same one. The energyband table contained in
>every observation row is the table which contains the different images
>for different filters for this observation. As the image for filter A
>for obs 0011020 is different than the image for filter A for obs 0011021
>there is no redundancy.

OK, I misunderstood your example.
Let me reformulate my concern using my own example:

Suppose that, along with giving access to all the observations resulting from
a SIA query, I want to provide Filter information (eg min and max wavelength of the filter).

Suppose that among all the N observations there are M observations
taken with the same filter (eg, F606W).

Obviously I do not want to repeat  the same min and max wavelength for each of 
the observations taken with the same filter.

How would you see this implemented in your scheme?


Regarding the grouping problem that you mentioned:

>How does the client "group" (and this is the key word we believe) the
>information coming from different projects, if we do not know _what_
>each of the resource tables inside it is describing?

I would say that the "type" attribute of a RESOURCE could be used for that,
in the "nested resources" model.
Again, I will ask Francois et al.(CDS) to comment on this.


Alberto



From owner-dal@eso.org  Fri Apr 16 15:13:51 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GDDWTk010238
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 15:13:32 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GDDWei010237
	for dal-outgoing; Fri, 16 Apr 2004 15:13:32 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GDDQTk010219;
	Fri, 16 Apr 2004 15:13:26 +0200 (MEST)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3GDDOTY018074;
	Fri, 16 Apr 2004 15:13:24 +0200 (CEST)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3GDDN90016483;
	Fri, 16 Apr 2004 15:13:23 +0200 (MET DST)
Received: from isol03.vilspa.esa.int (isol03.vilspa.esa.int [193.147.153.17])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i3GCoou3000038;
	Fri, 16 Apr 2004 14:50:50 +0200 (MEST)
Subject: Re: SIA Evolution Proposal
From: Pedro Osuna <posuna@iso.vilspa.esa.es>
To: Alberto Micol <Alberto.Micol@eso.org>
Cc: Pedro.Osuna@esa.int, js@iso.vilspa.esa.es, dal@ivoa.net, dm@ivoa.net
In-Reply-To: <407FBD40.6040900@eso.org>
References: <1082109962.19991.56.camel@isol03.vilspa.esa.int>
	 <407FBD40.6040900@eso.org>
Content-Type: text/plain
Message-Id: <1082119850.21015.35.camel@isol03.vilspa.esa.int>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) 
Date: Fri, 16 Apr 2004 14:50:50 +0200
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Pedro Osuna <posuna@iso.vilspa.esa.es>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Ciao Alberto,


with respect to using RESOURCEs inside RESOURCEs (as opposed to TABLES
inside TABLES) it is, in fact, the first option we considered when
looking at how to include IDHA structure in our XMM-Newton data after
the AVO demo.

However, we later realized that the RESOURCEs inside RESOURCEs would
allow for loads of description of metadata, but _not_ for inclusion of
proper hierarchy, as the TABLE data inside a RESOURCE can _not_ contain
another resource (as we said before) (FIELD elements inside TABLE can
_not_ have RESOURCEs inside, neither TABLEs) and therefore, you would
not be able to model any structure below a certain resource.

That's why we proposed the tables inside tables which solves the problem easily.


With respect to your filter example, maybe we are not understanding the problem 
correctly, but the answer for us would be clear: if you have several observations 
in the same filter, in your "display data model" (as we call it) you could model
your data as:

results -- Filter -- Observation 

instead of

results -- Observation -- Filter

such that you could put:


results	----  F6006W 	------	Obs 1
	|		 |-----  Obs 2
	|		 |-----  Obs 3
	|---- F8906G 	------  Obs 2
		 	 |------  Obs 12
			 |------  Obs 5

i.e., you would be "inverting" your display data model.

The description of the Filter, including filter-range, would appear only once in the
Filter's table "header".

This "Display Data Model", as we say in our note, does _not_ have to be identical
to your actual Data Model: it only has to reflect the way you want the SIAP results
to be structured. It is up to the Data providers to structure the way they want their
SIAP results to look like.


I hope this helps. Keep on waiting for more.....



Cheers,
P&J


On Fri, 2004-04-16 at 13:02, Alberto Micol wrote: 
> Dear Pedro,
> 
> >In our view, the CDS proposal using the current DTD allows for the
> >inclusion of several "parallel" <RESOURCE> elements with metadata
> >descriptions, but in the end does not solve the "structurization"
> >problem, as the results keep on being somehow flat. Parallel (i.e., same
> >level) <RESOURCE>s can not allow for structure inside. The CDS proposal
> >gives a <RESOURCE> of type "Results" and several others at the same
> >level. This is due to the fact that to allow for the inclusion of real
> >data inside the resource (i.e., to allow for structure), the resource's
> >TABLE _should_ allow to include inside it another RESOURCE (or another
> >TABLE, as we propose).
> 
> As said, the previous CDS proposal included nested resources
> and that allowed more structure. I hope Francois will comment on that.
> 
> But have you considered such option of nesting resourcing instead of tables?
> I find that cleaner ...
> 
> 
> >> Alberto wrote:
> >>
> >>The example by Pedro and Jesus shows a single record; but suppose that
> >>multiple records (say 4) are returned, and suppose that 2 observations
> >>were taken in energy band A and 2 observations were taken in energy band
> >>B. The same Energy_Band_Table will be seen in two different records for
> >>both the A filter and the B cases.
> >
> >Even when one filter appears in more than one "observation", the
> >energyband table is not the same one. The energyband table contained in
> >every observation row is the table which contains the different images
> >for different filters for this observation. As the image for filter A
> >for obs 0011020 is different than the image for filter A for obs 0011021
> >there is no redundancy.
> 
> OK, I misunderstood your example.
> Let me reformulate my concern using my own example:
> 
> Suppose that, along with giving access to all the observations resulting from
> a SIA query, I want to provide Filter information (eg min and max wavelength of the filter).
> 
> Suppose that among all the N observations there are M observations
> taken with the same filter (eg, F606W).
> 
> Obviously I do not want to repeat  the same min and max wavelength for each of 
> the observations taken with the same filter.
> 
> How would you see this implemented in your scheme?
> 
> 
> Regarding the grouping problem that you mentioned:
> 
> >How does the client "group" (and this is the key word we believe) the
> >information coming from different projects, if we do not know _what_
> >each of the resource tables inside it is describing?
> 
> I would say that the "type" attribute of a RESOURCE could be used for that,
> in the "nested resources" model.
> Again, I will ask Francois et al.(CDS) to comment on this.
> 
> 
> Alberto
> 

-- 
Pedro Osuna Alcalaya

 
Software Engineer
VILSPA Archive Development Team
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314
                                                                                
European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN

From owner-dal@eso.org  Fri Apr 16 15:53:26 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GDr5Tk016192
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 15:53:05 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GDr5Zh016191
	for dal-outgoing; Fri, 16 Apr 2004 15:53:05 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GDqrTk016130;
	Fri, 16 Apr 2004 15:52:53 +0200 (MEST)
Received: from eso.org (st14.hq.eso.org [134.171.10.25])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i3GDqrs02304;
	Fri, 16 Apr 2004 15:52:53 +0200 (MEST)
Message-ID: <407FE534.6000503@eso.org>
Date: Fri, 16 Apr 2004 15:52:52 +0200
From: Alberto Micol <Alberto.Micol@eso.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pedro Osuna <posuna@iso.vilspa.esa.es>
CC: js@iso.vilspa.esa.es, dal@ivoa.net, dm@ivoa.net
Subject: Re: SIA Evolution Proposal
References: <1082109962.19991.56.camel@isol03.vilspa.esa.int>	 <407FBD40.6040900@eso.org> <1082119850.21015.35.camel@isol03.vilspa.esa.int>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Dear Pedro,

What I think is important is to keep in mind that the user might want to
visualise "S?A" results her one way, regardless of the structure the
data provider has in mind.
That is, it is the client that should decide how to represent the data;
the default might be the "data provider way", but it shall be possible
for the user to group things in a different way.
Some user might want to group by waveband, some other by field of view,
some other by limiting magnitude, etc. It depends very much on the 
science s/he has in mind.

In this sense I'm inclined to think that it would be easier for the client
to be presented with a flat (and of course) normalised structure to 
start with.
The hierarchy could then be built on-the-fly according to user requirements.

>you could model your data as:
>
>results -- Filter -- Observation 
>
>instead of
>
>results -- Observation -- Filter
>
>such that you could put:
>
>
>results	----  F6006W 	------	Obs 1
>	|		 |-----  Obs 2
>	|		 |-----  Obs 3
>	|---- F8906G 	------  Obs 2
>		 	 |------  Obs 12
>			 |------  Obs 5
>
>i.e., you would be "inverting" your display data model.
>
>The description of the Filter, including filter-range, would appear only once in the
>Filter's table "header".
>

I see, so in this case the sw handling the results will find the 
wavelengths min and max
in the PARAMs of each Filter table, not in a central place (table) where 
all the filter
characteristics are stored as in the CDS proposal.
It looks to me that your model is indeed imposing the data provider view 
to the users.

Alberto


From owner-dal@eso.org  Fri Apr 16 16:29:11 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GESoTk021201
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 16:28:50 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GESnQi021198
	for dal-outgoing; Fri, 16 Apr 2004 16:28:49 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GESjTk021192;
	Fri, 16 Apr 2004 16:28:46 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3GESUTa021108;
	Fri, 16 Apr 2004 16:28:44 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i3GESKHI001968;
	Fri, 16 Apr 2004 08:28:21 -0600
Date: Fri, 16 Apr 2004 08:28:19 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Alberto Micol <Alberto.Micol@eso.org>
cc: Pedro Osuna <posuna@iso.vilspa.esa.es>, <js@iso.vilspa.esa.es>,
   <dal@ivoa.net>, <dm@ivoa.net>
Subject: Re: SIA Evolution Proposal
In-Reply-To: <407FE534.6000503@eso.org>
Message-ID: <Pine.LNX.4.44.0404160806520.20113-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi All -

On Fri, 16 Apr 2004, Alberto Micol wrote:
> What I think is important is to keep in mind that the user might want
> to visualise "S?A" results her one way, regardless of the structure the
> data provider has in mind.  That is, it is the client that should decide
> how to represent the data; the default might be the "data provider way",
> but it shall be possible for the user to group things in a different way.
> Some user might want to group by waveband, some other by field of view,
> some other by limiting magnitude, etc. It depends very much on the science
> s/he has in mind.
> 
> In this sense I'm inclined to think that it would be easier for the
> client to be presented with a flat (and of course) normalised structure
> to start with.  The hierarchy could then be built on-the-fly according
> to user requirements.

Thank you, Alberto for making this point.

The problem with an explicit hierarchy is that you have to pick one.
There are always multiple ways to visualize the same data.  It is
better to have a flat collection of data elements, and put the suggested
hierarchy in some sort of "view" element.  This also makes it easier for
generic tools which don't care about the hierarchy to navigate the data.
The only exception might be if the hierarchy represents some real physical
structuring of the data.  But then you probably have a structured object,
ie another data model.

Tables within tables, or any object more complex than an array within a
single table cell, are probably a bad idea.  This has been tried before
in other software and has never been that successful.  In the VO context
it is simply too complicated and I don't think the software would follow.
All the advantages of generic table tools go away if tables are no longer
tables.  Lets keep the table mechanism per se fairly simple, and use it for
tabular data.  If we need a general container mechanism there are better
ones than a table, e.g., the RESOURCE elements in VOTable provide a simple
container mechanism.

This is not to say that we can't map a data model into the fields of
a table.  Any catalog of any complexity is probably already doing this.
Just that we don't want to map a complex structured object into a single
field of a table.

	- Doug

From owner-dal@eso.org  Fri Apr 16 16:30:09 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GETqTk021403
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 16:29:52 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GETqt9021401
	for dal-outgoing; Fri, 16 Apr 2004 16:29:52 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GETnTk021390
	for <dal@ivoa.net>; Fri, 16 Apr 2004 16:29:49 +0200 (MEST)
Received: from athena.le.ac.uk (athena.le.ac.uk [143.210.16.127])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3GETmTY021279
	for <dal@ivoa.net>; Fri, 16 Apr 2004 16:29:48 +0200 (CEST)
Received: from [143.210.36.58] (helo=mail.star.le.ac.uk)
	by athena.le.ac.uk with smtp (Exim 4.30)
	id 1BEULj-0004nv-3b
	for dal@ivoa.net; Fri, 16 Apr 2004 15:29:47 +0100
Received: (qmail 8431 invoked from network); 16 Apr 2004 14:30:09 -0000
Received: from peneca.star.le.ac.uk (143.210.36.224)
  by mail.star.le.ac.uk with SMTP; 16 Apr 2004 14:30:09 -0000
Date: Fri, 16 Apr 2004 15:29:46 +0100 (BST)
From: Clive Page <cgp@star.le.ac.uk>
To: dm@ivoa.net, <dal@ivoa.net>
Subject: Re: SIA Evolution Proposal
In-Reply-To: <407FE534.6000503@eso.org>
Message-ID: <Pine.LNX.4.44L0.0404161522560.7692-100000@peneca.star.le.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Clive Page <cgp@star.le.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Fri, 16 Apr 2004, Alberto Micol wrote:

> >you could model your data as:
> >
> >results -- Filter -- Observation
> >
> >instead of
> >
> >results -- Observation -- Filter

> It looks to me that your model is indeed imposing the data provider view
> to the users.

I'm inclined to agree with Alberto here: of course the famous rules of
Codd and Date tell us never to duplicate data.  But here we have two
observations (which are pretty natural units in the astronomical world)
which just happen to have the same filter setting.  I don't see it as
terribly wasteful to have the filter values specified twice, once within
each observation chunk, even though that duplicates the information,
wastes file space, etc.  When you (or your software) access the data, I
would have thought it better to have the filter information in an expected
place than to have to root around in the structure for it.


-- 
Clive Page
Dept of Physics & Astronomy,
University of Leicester,
Leicester, LE1 7RH,  U.K.

From owner-dm@eso.org  Fri Apr 16 17:22:31 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GFMGTk027738
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 17:22:16 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GFMGAd027735
	for dm-outgoing; Fri, 16 Apr 2004 17:22:16 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GFM5Tk027716;
	Fri, 16 Apr 2004 17:22:05 +0200 (MEST)
Received: from eso.org (st14.hq.eso.org [134.171.10.25])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i3GFM5s05138;
	Fri, 16 Apr 2004 17:22:05 +0200 (MEST)
Message-ID: <407FFA1C.5050100@eso.org>
Date: Fri, 16 Apr 2004 17:22:04 +0200
From: Alberto Micol <Alberto.Micol@eso.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Clive Page <cgp@star.le.ac.uk>
CC: dm@ivoa.net, dal@ivoa.net
Subject: Re: SIA Evolution Proposal
References: <Pine.LNX.4.44L0.0404161522560.7692-100000@peneca.star.le.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


>But here we have two
>observations (which are pretty natural units in the astronomical world)
>which just happen to have the same filter setting.  I don't see it as
>terribly wasteful to have the filter values specified twice, once within
>each observation chunk
>

Yes Clive, I was thinking about that too.
Nevertheless, I'm used to live in a word that is a bit less than perfect;
apart from Iraqi or Palestinian or American (depends on your point of 
view) considerations,
here I mean that the speed of light is finite, and the bandwidth is what 
it is.
Hence, for more than just a couple of observations, I prefer not to 
duplicate
information.

Alberto
PS: Maybe it's too long that I work with RDBMSes, certainly I am always 
too worried
about things that could go wrong or slow. And the fact that I care about 
them does not
make my way of developing faster ... catch22 ... help!



From owner-dal@eso.org  Fri Apr 16 17:52:20 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GFq0Tk000988
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 17:52:00 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GFq0su000987
	for dal-outgoing; Fri, 16 Apr 2004 17:52:00 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GFpsTk000949;
	Fri, 16 Apr 2004 17:51:54 +0200 (MEST)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3GFprXe009335;
	Fri, 16 Apr 2004 17:51:53 +0200 (CEST)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3GFpqCO024747;
	Fri, 16 Apr 2004 17:51:52 +0200 (MET DST)
Received: from isol03.vilspa.esa.int (isol03.vilspa.esa.int [193.147.153.17])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i3GFTIu3011273;
	Fri, 16 Apr 2004 17:29:18 +0200 (MEST)
Subject: RE: SIA evolution proposal
From: Pedro Osuna <posuna@iso.vilspa.esa.es>
To: dal@ivoa.net, dm@ivoa.net
Cc: dtody@nrao.edu, Alberto.Micol@eso.org, po@iso.vilspa.esa.es,
   js@iso.vilspa.esa.es
Content-Type: text/plain
Message-Id: <1082129357.21015.85.camel@isol03.vilspa.esa.int>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) 
Date: Fri, 16 Apr 2004 17:29:17 +0200
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Pedro Osuna <posuna@iso.vilspa.esa.es>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear all,


we have the feeling that the discussion here is more on the line of
whether the SIAP should allow for structure or not. This is not the
point we were addressing in our note.

At the AVO demo, we were asked to include some structure in our SIAP
results, and the note we have sent proposes a solution to include _any_
type of hierarchy (not an explicit one) in them. 

If the IVOA decides not to put any hierarchy in the SIAP results, fine
for us. It seemed, however, logical to us to evolve the SIAP in the
direction of the Data Model.

On the other hand, in the examples we are discussing, Alberto wanted to
model different observations for the same filter, and however it seems
to end up asking to _not_ include any hierarchy, as flat structure is
preferred which, in our view, implies repetition. Then, it is the client
who has to be able to _model_ (from a flat table) the structure from a
_not_ known data model. This looks cumbersome to us. 

Again, if the question is "should we put structure in SIAP results?"
then it is not us who should answer neither do we claim to be in the
position to impose a specific way to follow.

Cheers,
P&J



On Fri, 2004-04-16 at 16:28, Doug Tody wrote: 
> Hi All -
> 
> On Fri, 16 Apr 2004, Alberto Micol wrote:
> > What I think is important is to keep in mind that the user might want
> > to visualise "S?A" results her one way, regardless of the structure the
> > data provider has in mind.  That is, it is the client that should decide
> > how to represent the data; the default might be the "data provider way",
> > but it shall be possible for the user to group things in a different way.
> > Some user might want to group by waveband, some other by field of view,
> > some other by limiting magnitude, etc. It depends very much on the science
> > s/he has in mind.
> > 
> > In this sense I'm inclined to think that it would be easier for the
> > client to be presented with a flat (and of course) normalised structure
> > to start with.  The hierarchy could then be built on-the-fly according
> > to user requirements.
> 
> Thank you, Alberto for making this point.
> 
> The problem with an explicit hierarchy is that you have to pick one.
> There are always multiple ways to visualize the same data.  It is
> better to have a flat collection of data elements, and put the suggested
> hierarchy in some sort of "view" element.  This also makes it easier for
> generic tools which don't care about the hierarchy to navigate the data.
> The only exception might be if the hierarchy represents some real physical
> structuring of the data.  But then you probably have a structured object,
> ie another data model.
> 
> Tables within tables, or any object more complex than an array within a
> single table cell, are probably a bad idea.  This has been tried before
> in other software and has never been that successful.  In the VO context
> it is simply too complicated and I don't think the software would follow.
> All the advantages of generic table tools go away if tables are no longer
> tables.  Lets keep the table mechanism per se fairly simple, and use it for
> tabular data.  If we need a general container mechanism there are better
> ones than a table, e.g., the RESOURCE elements in VOTable provide a simple
> container mechanism.
> 
> This is not to say that we can't map a data model into the fields of
> a table.  Any catalog of any complexity is probably already doing this.
> Just that we don't want to map a complex structured object into a single
> field of a table.
> 
> 	- Doug

                                              
-- 
Pedro Osuna Alcalaya

 
Software Engineer
VILSPA Archive Development Team
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314
                                                                                
European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From owner-dm@eso.org  Fri Apr 16 18:03:14 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GG2xTk002135
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 18:02:59 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GG2xxq002134
	for dm-outgoing; Fri, 16 Apr 2004 18:02:59 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GG2rTk002119;
	Fri, 16 Apr 2004 18:02:54 +0200 (MEST)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3GG2qXe009766;
	Fri, 16 Apr 2004 18:02:52 +0200 (CEST)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3GG2pvU025380;
	Fri, 16 Apr 2004 18:02:51 +0200 (MET DST)
Received: from isol03.vilspa.esa.int (isol03.vilspa.esa.int [193.147.153.17])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i3GFeIu3011604;
	Fri, 16 Apr 2004 17:40:18 +0200 (MEST)
Subject: Re: SIA Evolution Proposal
From: Pedro Osuna <posuna@iso.vilspa.esa.es>
To: Alberto Micol <Alberto.Micol@eso.org>
Cc: Pedro.Osuna@esa.int, Clive Page <cgp@star.le.ac.uk>, dm@ivoa.net,
   dal@ivoa.net
In-Reply-To: <407FFA1C.5050100@eso.org>
References: <Pine.LNX.4.44L0.0404161522560.7692-100000@peneca.star.le.ac.uk>
	 <407FFA1C.5050100@eso.org>
Content-Type: text/plain
Message-Id: <1082130018.21015.96.camel@isol03.vilspa.esa.int>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) 
Date: Fri, 16 Apr 2004 17:40:18 +0200
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Pedro Osuna <posuna@iso.vilspa.esa.es>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Sorry guys, but I've stopped to understand how from this morning:

[...]Obviously I do not want to repeat  the same min and max wavelength
for each of  the observations taken with the same filter.
[...]

we arrive to this other: 

[...]
>But here we have two observations (which are pretty natural units >in
the astronomical world) which just happen to have the same filter
>setting.  I don't see it as terribly wasteful to have the filter 
>values specified twice, once within each observation chunk
>
>>Yes Clive, I was thinking about that too.
[...]


P.

On Fri, 2004-04-16 at 17:22, Alberto Micol wrote:
> >But here we have two
> >observations (which are pretty natural units in the astronomical world)
> >which just happen to have the same filter setting.  I don't see it as
> >terribly wasteful to have the filter values specified twice, once within
> >each observation chunk
> >
> 
> Yes Clive, I was thinking about that too.
> Nevertheless, I'm used to live in a word that is a bit less than perfect;
> apart from Iraqi or Palestinian or American (depends on your point of 
> view) considerations,
> here I mean that the speed of light is finite, and the bandwidth is what 
> it is.
> Hence, for more than just a couple of observations, I prefer not to 
> duplicate
> information.
> 
> Alberto
> PS: Maybe it's too long that I work with RDBMSes, certainly I am always 
> too worried
> about things that could go wrong or slow. And the fact that I care about 
> them does not
> make my way of developing faster ... catch22 ... help!
> 
-- 
Pedro Osuna Alcalaya

 
Software Engineer
VILSPA Archive Development Team
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314
                                                                                
European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From owner-dm@eso.org  Fri Apr 16 18:50:13 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GGntTk006219
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 16 Apr 2004 18:49:55 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3GGntD5006218
	for dm-outgoing; Fri, 16 Apr 2004 18:49:55 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3GGnmTk006184;
	Fri, 16 Apr 2004 18:49:48 +0200 (MEST)
Received: from nmail1.systems.pipex.net (nmail1.systems.pipex.net [62.241.160.130])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3GGnkTY026504;
	Fri, 16 Apr 2004 18:49:46 +0200 (CEST)
Received: from nmail1.systems.pipex.net (localhost [127.0.0.1])
	by nmail1.systems.pipex.net (8.12.10/8.12.10) with ESMTP id i3GGnkK1027966;
	Fri, 16 Apr 2004 17:49:46 +0100
Received: (from nobody@localhost)
	by nmail1.systems.pipex.net (8.12.10/8.12.10/Submit) id i3GGnjT3027965;
	Fri, 16 Apr 2004 17:49:45 +0100
Received: from 143.210.36.13 ( [143.210.36.13])
	as user abm36@dial.pipex.com by netmail.pipex.net with HTTP;
	Fri, 16 Apr 2004 17:49:45 +0100
Message-ID: <1082134185.40800ea9e0fcf@netmail.pipex.net>
Date: Fri, 16 Apr 2004 17:49:45 +0100
From: martin hill <mchill@dial.pipex.com>
To: Clive Page <cgp@star.le.ac.uk>
Cc: dm@ivoa.net, dal@ivoa.net
Subject: Re: SIA Evolution Proposal
References: <Pine.LNX.4.44L0.0404161522560.7692-100000@peneca.star.le.ac.uk>
In-Reply-To: <Pine.LNX.4.44L0.0404161522560.7692-100000@peneca.star.le.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
User-Agent: PIPEX NetMail (IMP3.1)
X-Originating-IP: 143.210.36.13
X-PIPEX-Username: abm36%dial.pipex.com
X-Usage: PIPEX NetMail is subject to the standard PIPEX terms and conditions of use
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: martin hill <mchill@dial.pipex.com>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

If I understand this right, you're saying you want to associate the same data 
with several elements.  For example, a set of observations of several thousand 
objects might have been carried out using two or three filters.

There is an 'XPointer' concept for XML documents which allows you to do this.  
Basically you can describe the filter in some metadata bit, giving it an 
attribute 'ID' and assigning it a unique reference.   Then you refer to that ID 
in an attribute or element in the main data using the XPointer format. 

This is pretty standard now (W3C have adopted it I believe) and seems to solve 
what you want; it also means you can happily describe the filter in as much 
detail as you like without having it all replicated throughout the list.

Cheers,

Martin


Quoting Clive Page <cgp@star.le.ac.uk>:

> On Fri, 16 Apr 2004, Alberto Micol wrote:
> 
> > >you could model your data as:
> > >
> > >results -- Filter -- Observation
> > >
> > >instead of
> > >
> > >results -- Observation -- Filter
> 
> > It looks to me that your model is indeed imposing the data provider view
> > to the users.
> 
> I'm inclined to agree with Alberto here: of course the famous rules of
> Codd and Date tell us never to duplicate data.  But here we have two
> observations (which are pretty natural units in the astronomical world)
> which just happen to have the same filter setting.  I don't see it as
> terribly wasteful to have the filter values specified twice, once within
> each observation chunk, even though that duplicates the information,
> wastes file space, etc.  When you (or your software) access the data, I
> would have thought it better to have the filter information in an expected
> place than to have to root around in the structure for it.
> 
> 
> -- 
> Clive Page
> Dept of Physics & Astronomy,
> University of Leicester,
> Leicester, LE1 7RH,  U.K.
> 
> 
> 


-- 
Martin Hill
07901 55 24 66
www.mchill.net

From owner-dal@eso.org  Sun Apr 18 01:25:30 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3HNOk6B001336
	for <dal-outgoing@mercury.hq.eso.org>; Sun, 18 Apr 2004 01:24:46 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3HNOkXk001335
	for dal-outgoing; Sun, 18 Apr 2004 01:24:46 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3HNOe6B001319;
	Sun, 18 Apr 2004 01:24:41 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3HNObTY003965;
	Sun, 18 Apr 2004 01:24:39 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3HNOZUI001619
          ; Sun, 18 Apr 2004 01:24:36 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id BAA08274;
	Sun, 18 Apr 2004 01:20:04 +0200 (MET DST)
Date: Sun, 18 Apr 2004 01:20:04 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404172320.BAA08274@alinda.u-strasbg.fr>
To: cgp@star.le.ac.uk, mchill@dial.pipex.com
Subject: Re: SIA Evolution Proposal
Cc: dal@ivoa.net, dm@ivoa.net
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear All,
    I try to comment or answer to all the mails sent in reply to SIA Evolution proposal since Thursday.
This will probably not be complete, but anyway.
I start by the end (nearly, because I will  adress Martin's one only on Monday)  
Pedro and Jesus:
--------------------------------------------------------------------------------------------------------------------------
If the IVOA decides not to put any hierarchy in the SIAP results, fine 
for us. It seemed, however, logical to us to evolve the SIAP in the 
direction of the Data Model. 
....
Again, if the question is "should we put structure in SIAP results?" 
then it is not us who should answer neither do we claim to be in the 
position to impose a specific way to follow
-------------------------------------------------------------------------------------------------------------------------------
No, Pedro I don't think anybody here (apart from Clive, maybe: I will answer to this later if necessary)
 is refusing to put structure in SIA or whatever IVOA DAL protocol. Even Doug if I remember well
some long discussions I had with him does'nt refuse some structuration. And he concludes:
------------------------------------------------------------------------------------------------------------------------------------
This is not to say that we can't map a data model into the fields of 
a table. Any catalog of any complexity is probably already doing this. 
Just that we don't want to map a complex structured object into a single 
field of a table. 
----------------------------------------------------------------------------------------------------------------------------------------
The problem is to find the best way to do it. To clarify for other readers than the current protagonists,
I recall that they are three notes from CDS: A general one called "data model serialisation in VOTable"
(see this discussion list)
which explains very basic rules to structure a VOTable document according to a given datamodel.
These rules have been applied for the AVO demo metadatree since 2002, using the IDHA model, in the
 format we call "IDHA format" (ref in the previous note). THis format is hierarchical, using nested
 RESOURCES. The "SIA Evolution proposal" we are discussing here is also based on the same set of
 rules, and allows to build STRUCTURED documents but  they are not HIERARCHICAL. 
The main reason for doing this step "backwards" (would say some of you) was to try to take into
account the remarks made by Doug and confirmed by Alberto:
----------------------------------------------------------------------------------------------------------------------------------------
The problem with an explicit hierarchy is that you have to pick one. 
There are always multiple ways to visualize the same data. It is 
better to have a flat collection of data elements, and put the suggested 
hierarchy in some sort of "view" element. This also makes it easier for 
generic tools which don't care about the hierarchy to navigate the data. 

That is, it is the client that should decide 
> how to represent the data; the default might be the "data provider way", 
> but it shall be possible for the user to group things in a different way. 
> Some user might want to group by waveband, some other by field of view, 
> some other by limiting magnitude, etc. It depends very much on the science 
> s/he has in mind. 
> 
------------------------------------------------------------------------------------------
In our "SIA Evolution proposal" where is the structure coming from ? Answer: from the references: 
references  from FIELDS to FIELDS ID for associations and references from FIELDS to TABLES ID for 
composition (The "Packaging" Table referenced in the "acref" field of our example is of this kind)
 And this is the key of the solution of the CDS/VILSPA debate I think: Pedro and Jesus if you use
 references to tables in the "complex fields" instead of  nested tables you achieve the same result,
I guess. I will try to rewrite your example next Monday, using this idea, which do not requires any 
change to the VOTable DTD.
BTW, Alberto this is also the answer to this question:
------------------------------------------------------------------------------------------------------------------------------
What is also not clear is how, with the new proposed CDS structure, one 
could describe multiple members of observations. In the previous IDHA 
version 
that was achieved with "nested resources"; but now? 
-------------------------------------------------------------------------------------------------------------------------
In the packaging we can have a field referencing to a table of subobservations ( These two
tables probably have to be grouped in the same RESOURCE in that case.)
 
One last answer to Alberto:
-------------------------------------------------------------------------------------------------------------------------------
I would say that the "type" attribute of a RESOURCE could be used for that, 
in the "nested resources" model. 
----------------------------------------------------------------------------
Yes Alberto: "type" (or "name") of RESOURCES are the good attributes
to use to tell which kind of data we have there. Because you can repeat 
as many RESOURCES you want like that in the document, as if it were
different instances of the same class.

Regards to all
François   
SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dm@eso.org  Sun Apr 18 11:05:26 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3I94t6B014198
	for <dm-outgoing@mercury.hq.eso.org>; Sun, 18 Apr 2004 11:04:55 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3I94tbK014197
	for dm-outgoing; Sun, 18 Apr 2004 11:04:55 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3I94q6B014187
	for <dm@ivoa.net>; Sun, 18 Apr 2004 11:04:52 +0200 (MEST)
Received: from artemis.le.ac.uk (mailsend.le.ac.uk [143.210.16.126])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3I94oXe026007
	for <dm@ivoa.net>; Sun, 18 Apr 2004 11:04:50 +0200 (CEST)
Received: from [143.210.36.58] (helo=mail.star.le.ac.uk)
	by artemis.le.ac.uk with smtp (Exim 4.30)
	id 1BF8EL-0007Hk-HK
	for dm@ivoa.net; Sun, 18 Apr 2004 10:04:49 +0100
Received: (qmail 17975 invoked from network); 18 Apr 2004 09:05:11 -0000
Received: from sparky.star.le.ac.uk (143.210.36.10)
  by mail.star.le.ac.uk with SMTP; 18 Apr 2004 09:05:11 -0000
Date: Sun, 18 Apr 2004 10:05:10 +0100 (BST)
From: Clive Page <cgp@star.le.ac.uk>
To: dal@ivoa.net
cc: dm@ivoa.net
Subject: Re: SIA Evolution Proposal
In-Reply-To: <200404172320.BAA08274@alinda.u-strasbg.fr>
Message-ID: <Pine.GSO.4.44L0.0404180959300.3819-100000@sparky.star.le.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Clive Page <cgp@star.le.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Sun, 18 Apr 2004, Francois Bonnarel wrote:

> No, Pedro I don't think anybody here (apart from Clive, maybe: I will
> answer to this later if necessary)
>  is refusing to put structure in SIA or whatever IVOA DAL protocol.

Just a short clarification which may save you having to compose a reply to
me: I do not at all oppose putting structures in SIA, just pointing out
that in some cases it isn't so bad to duplicate a small amount of data if
it keeps the structure simpler.  A normalised dataset is very elegant in
theory, not always good in practice.


-- 
Clive Page
Dept of Physics & Astronomy,
University of Leicester,
Leicester, LE1 7RH,  U.K.

From owner-dm@eso.org  Sun Apr 18 15:29:29 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3IDSp6B025752
	for <dm-outgoing@mercury.hq.eso.org>; Sun, 18 Apr 2004 15:28:52 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3IDSpXu025751
	for dm-outgoing; Sun, 18 Apr 2004 15:28:51 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3IDSm6B025746;
	Sun, 18 Apr 2004 15:28:49 +0200 (MEST)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3IDSlTY016448;
	Sun, 18 Apr 2004 15:28:47 +0200 (CEST)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1BFCLh-0000Ck-PZ; Sun, 18 Apr 2004 14:28:41 +0100
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1BFCLh-0003ON-00; Sun, 18 Apr 2004 14:28:41 +0100
Date: Sun, 18 Apr 2004 14:28:41 +0100 (BST)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
cc: cgp@star.le.ac.uk, mchill@dial.pipex.com, dal@ivoa.net, dm@ivoa.net
Subject: Re: SIA Evolution Proposal
In-Reply-To: <200404172320.BAA08274@alinda.u-strasbg.fr>
Message-ID: <Pine.GSO.4.53.0404181423030.5248@adikia>
References: <200404172320.BAA08274@alinda.u-strasbg.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BFCLh-0000Ck-PZ*BUGbWeM3D9U*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


I would just like to back up Francois by saying that I would have found it
almost impossible to do the sort of science which we did with the AVO
Demo, involving selecting and comparing hundreds of images and spectra, at
resolutions from 50 mas to arcmin, without heirachical data access.  At
least, the alternative would have been to do it the old way, searching
through long lists by hand or having to zoom in and wait for images to
redisplay. For datacubes, it is the answer to a vsiualisation problem
which has been bugging me for years and it could be adapted to multi-epoch
or multi-polaization data too.  Much quicker to have the meta-data
available on multiple scales and for images, catalogues and spectra!

I do think that IDHA is still a bit opticl specific but that's easy to
fix...

cheers
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).


From owner-dal@eso.org  Sun Apr 18 23:50:36 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3ILo4vB028361
	for <dal-outgoing@mercury.hq.eso.org>; Sun, 18 Apr 2004 23:50:04 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3ILo47A028360
	for dal-outgoing; Sun, 18 Apr 2004 23:50:04 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3ILnwvB028319;
	Sun, 18 Apr 2004 23:49:58 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3ILntTY026654;
	Sun, 18 Apr 2004 23:49:57 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3ILnrUI045647
          ; Sun, 18 Apr 2004 23:49:53 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id XAA14852;
	Sun, 18 Apr 2004 23:45:20 +0200 (MET DST)
Date: Sun, 18 Apr 2004 23:45:20 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404182145.XAA14852@alinda.u-strasbg.fr>
To: amsr@jb.man.ac.uk
Subject: Re: SIA Evolution Proposal
Cc: cgp@star.le.ac.uk, dal@ivoa.net, dm@ivoa.net, mchill@dial.pipex.com
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Thank you Anita,
    When I was speaking yesterday of going backwards from Hierachical 
structure to a simple structure with references fields, I spoke only
from the VOTable documents wwe are using for DAL purposes. In my 
mind the interfaces in the AVO , or the IVOA have to provide hierarchical
(or lattice) browsers like the metadatree. We haaave assesed that the kind
of format we proposed for SIAP evolution makes this easy.
Regards
François
<
<I would just like to back up Francois by saying that I would have found it
<almost impossible to do the sort of science which we did with the AVO
<Demo, involving selecting and comparing hundreds of images and spectra, at
<resolutions from 50 mas to arcmin, without heirachical data access.  At
<least, the alternative would have been to do it the old way, searching
<through long lists by hand or having to zoom in and wait for images to
<redisplay. For datacubes, it is the answer to a vsiualisation problem
<which has been bugging me for years and it could be adapted to multi-epoch
<or multi-polaization data too.  Much quicker to have the meta-data
<available on multiple scales and for images, catalogues and spectra!
<
<I do think that IDHA is still a bit opticl specific but that's easy to
<fix...
<
<cheers
<a
<
<- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<Dr. Anita M. S. Richards, AVO Astronomer
<MERLIN/VLBI National Facility, University of Manchester,
<Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
<tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
<
<
SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Mon Apr 19 18:01:19 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3JG0pnY011138
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 19 Apr 2004 18:00:51 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3JG0pGV011135
	for dal-outgoing; Mon, 19 Apr 2004 18:00:51 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3JG0hnY011111;
	Mon, 19 Apr 2004 18:00:43 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3JG0gTY025048;
	Mon, 19 Apr 2004 18:00:42 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3JG0fUI026921
          ; Mon, 19 Apr 2004 18:00:41 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id RAA21602;
	Mon, 19 Apr 2004 17:56:08 +0200 (MET DST)
Date: Mon, 19 Apr 2004 17:56:08 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404191556.RAA21602@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: Re: SIA Evolution proposal
X-Antivirus: scanned by sophos at u-strasbg.fr
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi all,
A couple of days ago I received a couple of comments from Markus Dolensky
on a preliminary version of the SIAP Evolution proposal. Here are these
comments with my answers.    

<- From a conceptual viewpoint we doubt, however, that IDHA should be 
<piggybacked onto a 'simple' access protocol; backward compatibility aside - 
<it should be the other way round: there is a hierarchical representation of 
<metadata which can be serialized into XML and it may have (CS, SIA, SSA, ADQL, 
<...) access references in it's nodes.
  ---> I think I don't agree with that. SIA/SSA are allready describing
metadata, although in a flat manner. I think it is possible to add structure
in the result in order to reflect more relationships and concepts from the
data model. If we have a totally independant hierarchical representation of
metadata we do not need SIA/SSA any more.

<- if special schema for individual object classes have already been defined 
<(http://www.ivoa.net/xml/), then they should be reused; this means (allowing 
<to) extend the vocabulary beyond the VOTable.dtd.
  ----> That's a good point but I do not see which one I could use at the
moment.

<- since IDHA is one (observation oriented) data model, we need to make 
<provisions to allow similar extensions for other (types of) models
   ----> We think the kind of mechanisms we defined is fully usable for other
data models than the single IDHA. We plan to build ans example with IVOA
Observation draft.

<- attributes in the additional tables should use the utype + URI mechanism (new 
<VOTable 1.1 feature) to uniquely identify data model items; see 
<http://www.ivoa.net/forum/votable/0327.htm
    ----> We added utypes in the example currently on line , slightly different
from the one you have seen.

<- about URL templates:
<What kind of functionality does it provide that cannot be achieved by narrowing 
<down a query using constraints like &FORMAT=MIME-TYPE?
<Remember that an SIA service can define arbitrary optional query parameters. Do 
<we have two redundant ways of achieving the same thing and if so do we need both?
    -----> This point has been extensivly discussed with Doug Tody several
month ago. For example a cutout service requires a free central position
within certain limits. See a discussion of this in :
 http://www.ivoa.net/forum/dal/0075.htm
Using arbitrary optional query parameters suppose that they can be defined
a priori fo the whole service. The URL templating is supposed to be observation
dependant.

<- the proposal does not mention any implications on querying: it seems that a 
<service has to return all possible extension tables; there doesn't seem to be a 
<way that a client can request a specific extension table like WCS info. This 
<potentially increases the overhead and required network bandwidth enormously.
    ----> This is a very good point, we totally focussed on the answer. But
the Request/answer matching will rely on the use of different classes of the
datamodel in each case I Guess. We will check this before Boston.

SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Mon Apr 19 20:02:50 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3JI2WnY022571
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 19 Apr 2004 20:02:32 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3JI2WBS022570
	for dal-outgoing; Mon, 19 Apr 2004 20:02:32 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3JI2LnY022542;
	Mon, 19 Apr 2004 20:02:21 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3JI2JXe012137;
	Mon, 19 Apr 2004 20:02:20 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3JI2GUI017907
          ; Mon, 19 Apr 2004 20:02:16 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id TAA22151;
	Mon, 19 Apr 2004 19:57:43 +0200 (MET DST)
Date: Mon, 19 Apr 2004 19:57:43 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404191757.TAA22151@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net, posuna@iso.vilspa.esa.es
Subject: Re: A note on a possible extension to SIAP
Cc: Christophe.Arviset@esa.int, js@iso.vilspa.esa.es, po@iso.vilspa.esa.es
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Jesus and Pedro,
  
     As I annouced in my mail last week-end I took your example
and modified it a little bit by introducing in your peculiar fields
"EXposure_Table" "Source_Table" and "Energy_Band_Table" a "VOTable
ref" to a corresponding Table ID which one can find further in the
VOTable document.
   In addition I created a "DIS:LowerLevelTable" pseudo UCD (DIS for
discussion) which may be not necessary because the occurence of the
reference may be sufficient to identify such kind of fields.
   I added the upper level Table Identifier field (ObsId) in the Exposure 
one in order to joint the Observation and Exposure Tables.
   Something similar would have to be done in Source and Energy_Band 
Tables which I was to lazy to complete!
   If I didn't misunderstood your example I Think this is a serialization
of your data model at page 2, using some of the rules we described with
Mireille in our "Data Model serialization in VOTable" note.
   This is done without modifying the VOTable DTD, which I think is reasonable
for Boston, because there has been a very long process of discussion for
version 1.1.

Cheers
François

   

<?xml version = "1.0" ?>
  <!DOCTYPE VOTABLE (View Source for full doctype...)>
<VOTABLE version = "1.0">
<RESOURCE type="results">
   <DESCRIPTION> XMM-Newton Simple Image Protocol (SIAP) Service</DESCRIPTION>
   <INFO name="QUERY_STATUS" value="OK" />
  <TABLE ID="Observation">
    <FIELD ID="ObsId" ucd="OBS_ID" datatype="char" arraysize="*" />
    <FIELD ID="Target_Name" ucd="OBS_ID" datatype="char" arraysize="*" />
    <FIELD ID="Start_Time" ucd="VOX:OBS_START_TIME" datatype="char" arraysize="*" />
    <FIELD ID="End_Time" ucd="VOX:OBS_END_TIME" datatype="char" arraysize="*" />
    <FIELD ID="On_Time" ucd="VOX:OBS_DURATION" datatype="int"  />
    <FIELD ID="RA" ucd="POS_EQ_RA_MAIN" datatype="char" arraysize="*" />
    <FIELD ID="DEC" ucd="POS_EQ_DEC_MAIN" datatype="char" arraysize="*" />
    <FIELD ID="FOV" ucd="VOX:Field_Of_View" datatype="char" arraysize="*" />
    <FIELD ID="FORMAT" ucd="VOX:Image_Format" datatype="char" arraysize="*" />
    <FIELD ID="Reference" ucd="DATA_LINK" datatype="char" arraysize="*" />
    <FIELD ID="Exposure_Table" ucd="DIS:LowerLevelTable" datatype="char" arraysize="*" ref= "Exposure" />
    <DATA>
       <TABLEDATA>
          <TR>
            <TD>0102640101</TD>
            <TD>XMM EPIC Target M33_1 </TD>
            <TD>2000-08-04 05:16:00.0 </TD>
            <TD>2000-08-04 10:27:12.0 </TD>
            <TD>18672</TD>
            <TD>23.458305</TD>
            <TD>30.66414</TD>
            <TD>0.72x0.72</TD>
            <TD>image/fits</TD> 
            <TD>
                <![CDATA[http://xsa.vilspa.esa.es:8080/alo/jsp?obsno=0102640101&name=OIMAGE&level=PPS&extension=FTZ&protocol=HTTP]]>
            </TD>
            <TD>Exposure_Table</TD>
          </TR>
        </TABLEDATA>
      </DATA>
    </TABLE>
  <TABLE ID="Exposure">
    <FIELD ref="ObsId" />
    <FIELD ID="ExposureNumber" ucd="EXP_ID" datatype="char" arraysize="*" />
    <FIELD ID="Image_Name" ucd="VOX:Image_Title" datatype="char" arraysize="*" />
    <FIELD ID="Instrument" ucd="VOX:INST_ID" datatype="char" arraysize="*" />
    <FIELD ref="Start_Time"  />
    <FIELD ref="End_Time"  />
    <FIELD ref="On_Time"  />
    <FIELD ref="RA"  />
    <FIELD ref="DEC"  />
    <FIELD ref="FOV" />
    <FIELD ref="FORMAT"  />
    <FIELD ref="Reference"  />
    <FIELD ID="Source_Table" ucd="DIS:LowerLevelTable" datatype="char" arraysize="*" ref= "Source" />
    <FIELD ID="Energy_Band_Table" ucd="DIS:LowerLevelTable" datatype="char" arraysize="*" ref= "Energy_Band" />
    <DATA>
    <DATA>
       <TABLEDATA>
          <TR>
            <TD>0102640101</TD>
            <TD>S001</TD>
            <TD>XMM EPIC EPN Image. Target : M31Core . Exposure S001 </TD>
            <TD>2000-08-04 06:06:43.0 </TD>
            <TD>2000-08-04 09:51:52.0 </TD>
            <TD>13509</TD>
            <TD>23.458305</TD>
            <TD>30.66414</TD>
            <TD>0.72x0.72</TD>
            <TD>image/fits</TD> 
            <TD>
                <![CDATA[http://xsa.vilspa.esa.es:8080/alo/jsp?obsno=0102640101&&instname=PN&datasubsetno=8&name=IMAGE&level=PPS&extension=FTZ&protocol=HTTP]]>
            </TD>
            <TD>Source_Table</TD>
            <TD>Energy_Band_Table</TD>
          </TR>
        </TABLEDATA>
      </DATA>
    </TABLE>
    <TABLE ID = "Source">
      .......
    </TABLE>
    <TABLE ID = "Energy_Band">
      ......
    </TABLE>
SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dm@eso.org  Tue Apr 20 15:39:48 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KDdR1U014654
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 20 Apr 2004 15:39:28 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3KDdRIv014653
	for dm-outgoing; Tue, 20 Apr 2004 15:39:27 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KDdO1U014643;
	Tue, 20 Apr 2004 15:39:24 +0200 (MEST)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3KDdLTY001762;
	Tue, 20 Apr 2004 15:39:22 +0200 (CEST)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3KDdKSv029744;
	Tue, 20 Apr 2004 15:39:20 +0200 (MET DST)
Received: from isol03.vilspa.esa.int (isol03.vilspa.esa.int [193.147.153.17])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i3KDGku3010917;
	Tue, 20 Apr 2004 15:16:46 +0200 (MEST)
Subject: Re: A note on a possible extension to SIAP
From: Pedro Osuna <posuna@iso.vilspa.esa.es>
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Cc: dal@ivoa.net, dm@ivoa.net, js@iso.vilspa.esa.es, po@iso.vilspa.esa.es,
   Christophe.Arviset@esa.int
In-Reply-To: <200404191757.TAA22151@alinda.u-strasbg.fr>
References: <200404191757.TAA22151@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=
Message-Id: <1082467006.6351.216.camel@isol03.vilspa.esa.int>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) 
Date: Tue, 20 Apr 2004 15:16:46 +0200
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Pedro Osuna <posuna@iso.vilspa.esa.es>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Francois,

this new approach, where you include different tables in the same
RESOURCE  results, is closer to what we propose.

Although we like it more than your previous proposal, we have been
looking at the pros and cons of your approach vs ours, and these are the
conclusions we have drawn. We think there is no-single solution for this
issue, but also believe it is good to post these ideas to the whole
community for discussion. Here they go:


In your example, a table "points" to a structure which is outside itself
(another table). This is to avoid modification of the DTD to allow
tables inside tables. All the tables appear, therefore, at the same
level.

This means that the external tables do have to have an identifier to be
able to do the joins among tables. 

This would be an exact mapping of how an RDBMS works: independent tables
joined through identifiers. 

The problem with this approach is that it leaves the whole of the
interpretation of the structure to the client. 

As the service is hiding the structure (it does not have any structure
by itself, only pointers and identifiers to be able to do joins), the
client will have to re-interpret it. In the case of a couple of
observations, this could be done fast. In the case of hundreds of
observations, in your approach the client would have to go through the
whole results for each and every observation to figure out which
exposures belong to it (and later, for each and every exposure to find
the sources, etc.).

As the results given in your way do not contain any specific ordering,
the display client will have to make this ordering by itself. This
reordering would be done _without_ indexes (in the database terminology
sense) and therefore would be a very un-efficient task. In our case,
however, indexes are implicit in the structure itself, as
"substructures" (as exposures, sources, etc.) are already inserted below
a specific "superstructure" (like observation) and therefore the client
only travels the structures once. 

In our proposal, therefore, the join issues are handled at the server
level, and the structure is already unveiled to the client, which would
only have to display it in one go.


Another "artifact" of your proposal is the use of those "dummy"
placeholders:

<TD>Exposure_Table</TD>

These ones appear due to the fact that VOTable is imposing to have an
entry per FIELD, and thus the <FIELD ID=Exposure_Table>, which in our
case goes _inside_ the TABLE, has to have a dummy <TD> in your case as
it points to an outside table. 

This might look like cosmetics thing, but in our view it reveals an
inconsistency between the VOTable real requirements and the way we would
use the VOTables in your example. Of course, this problem would be
solved by modifying somehow the DTD.

As a last example we were trying to use to clarify our own ideas, we
were identifying the structure we wanted to include in the SIAP to a
file system directory structure. In our approach, we send the directory
structure directly to the client, allowing it to display it the way it
wants. In your approach, a very simple directory structure would be
completely flat, with each subdirectory containing a pointer to the
directory where it hangs from, allowing to "join" directories and
subdirectories. Instead of giving the structure directly to the client,
you give it the tools to create the structure, but then it is the client
which has to do the whole process of "structurization". Although a valid
approach, we believe that the time spent by the client in doing this
should be spent by the server, which in the end is doing an asynchronous
work with the rest of the servers being requested.


Anyway, we believe this approach is much close to our idea of how things
should work, and we think we are working towards a positive evolution
for SIAP results. 

Best regards,
P&J


-- 
Pedro Osuna Alcalaya

 
Software Engineer
VILSPA Archive Development Team
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314
                                                                                
European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN

On Mon, 2004-04-19 at 19:57, Francois Bonnarel wrote:
> Dear Jesus and Pedro,
>   
>      As I annouced in my mail last week-end I took your example
> and modified it a little bit by introducing in your peculiar fields
> "EXposure_Table" "Source_Table" and "Energy_Band_Table" a "VOTable
> ref" to a corresponding Table ID which one can find further in the
> VOTable document.
>    In addition I created a "DIS:LowerLevelTable" pseudo UCD (DIS for
> discussion) which may be not necessary because the occurence of the
> reference may be sufficient to identify such kind of fields.
>    I added the upper level Table Identifier field (ObsId) in the Exposure 
> one in order to joint the Observation and Exposure Tables.
>    Something similar would have to be done in Source and Energy_Band 
> Tables which I was to lazy to complete!
>    If I didn't misunderstood your example I Think this is a serialization
> of your data model at page 2, using some of the rules we described with
> Mireille in our "Data Model serialization in VOTable" note.
>    This is done without modifying the VOTable DTD, which I think is reasonable
> for Boston, because there has been a very long process of discussion for
> version 1.1.
> 
> Cheers
> FranÃ§ois
> 
>    
> 
> <?xml version = "1.0" ?>
>   <!DOCTYPE VOTABLE (View Source for full doctype...)>
> <VOTABLE version = "1.0">
> <RESOURCE type="results">
>    <DESCRIPTION> XMM-Newton Simple Image Protocol (SIAP) Service</DESCRIPTION>
>    <INFO name="QUERY_STATUS" value="OK" />
>   <TABLE ID="Observation">
>     <FIELD ID="ObsId" ucd="OBS_ID" datatype="char" arraysize="*" />
>     <FIELD ID="Target_Name" ucd="OBS_ID" datatype="char" arraysize="*" />
>     <FIELD ID="Start_Time" ucd="VOX:OBS_START_TIME" datatype="char" arraysize="*" />
>     <FIELD ID="End_Time" ucd="VOX:OBS_END_TIME" datatype="char" arraysize="*" />
>     <FIELD ID="On_Time" ucd="VOX:OBS_DURATION" datatype="int"  />
>     <FIELD ID="RA" ucd="POS_EQ_RA_MAIN" datatype="char" arraysize="*" />
>     <FIELD ID="DEC" ucd="POS_EQ_DEC_MAIN" datatype="char" arraysize="*" />
>     <FIELD ID="FOV" ucd="VOX:Field_Of_View" datatype="char" arraysize="*" />
>     <FIELD ID="FORMAT" ucd="VOX:Image_Format" datatype="char" arraysize="*" />
>     <FIELD ID="Reference" ucd="DATA_LINK" datatype="char" arraysize="*" />
>     <FIELD ID="Exposure_Table" ucd="DIS:LowerLevelTable" datatype="char" arraysize="*" ref= "Exposure" />
>     <DATA>
>        <TABLEDATA>
>           <TR>
>             <TD>0102640101</TD>
>             <TD>XMM EPIC Target M33_1 </TD>
>             <TD>2000-08-04 05:16:00.0 </TD>
>             <TD>2000-08-04 10:27:12.0 </TD>
>             <TD>18672</TD>
>             <TD>23.458305</TD>
>             <TD>30.66414</TD>
>             <TD>0.72x0.72</TD>
>             <TD>image/fits</TD> 
>             <TD>
>                 <![CDATA[http://xsa.vilspa.esa.es:8080/alo/jsp?obsno=0102640101&name=OIMAGE&level=PPS&extension=FTZ&protocol=HTTP]]>
>             </TD>
>             <TD>Exposure_Table</TD>
>           </TR>
>         </TABLEDATA>
>       </DATA>
>     </TABLE>
>   <TABLE ID="Exposure">
>     <FIELD ref="ObsId" />
>     <FIELD ID="ExposureNumber" ucd="EXP_ID" datatype="char" arraysize="*" />
>     <FIELD ID="Image_Name" ucd="VOX:Image_Title" datatype="char" arraysize="*" />
>     <FIELD ID="Instrument" ucd="VOX:INST_ID" datatype="char" arraysize="*" />
>     <FIELD ref="Start_Time"  />
>     <FIELD ref="End_Time"  />
>     <FIELD ref="On_Time"  />
>     <FIELD ref="RA"  />
>     <FIELD ref="DEC"  />
>     <FIELD ref="FOV" />
>     <FIELD ref="FORMAT"  />
>     <FIELD ref="Reference"  />
>     <FIELD ID="Source_Table" ucd="DIS:LowerLevelTable" datatype="char" arraysize="*" ref= "Source" />
>     <FIELD ID="Energy_Band_Table" ucd="DIS:LowerLevelTable" datatype="char" arraysize="*" ref= "Energy_Band" />
>     <DATA>
>     <DATA>
>        <TABLEDATA>
>           <TR>
>             <TD>0102640101</TD>
>             <TD>S001</TD>
>             <TD>XMM EPIC EPN Image. Target : M31Core . Exposure S001 </TD>
>             <TD>2000-08-04 06:06:43.0 </TD>
>             <TD>2000-08-04 09:51:52.0 </TD>
>             <TD>13509</TD>
>             <TD>23.458305</TD>
>             <TD>30.66414</TD>
>             <TD>0.72x0.72</TD>
>             <TD>image/fits</TD> 
>             <TD>
>                 <![CDATA[http://xsa.vilspa.esa.es:8080/alo/jsp?obsno=0102640101&&instname=PN&datasubsetno=8&name=IMAGE&level=PPS&extension=FTZ&protocol=HTTP]]>
>             </TD>
>             <TD>Source_Table</TD>
>             <TD>Energy_Band_Table</TD>
>           </TR>
>         </TABLEDATA>
>       </DATA>
>     </TABLE>
>     <TABLE ID = "Source">
>       .......
>     </TABLE>
>     <TABLE ID = "Energy_Band">
>       ......
>     </TABLE>
> SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>
> 
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
> 
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
> ---------------------------------------------------------------------
-- 
Pedro Osuna Alcalaya

 
Software Engineer
VILSPA Archive Development Team
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314
                                                                                
European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From owner-dal@eso.org  Tue Apr 20 16:19:06 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KEIj1U020722
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 20 Apr 2004 16:18:46 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3KEIjGZ020720
	for dal-outgoing; Tue, 20 Apr 2004 16:18:45 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KEIU1U020679;
	Tue, 20 Apr 2004 16:18:30 +0200 (MEST)
Received: from eso.org (st14.hq.eso.org [134.171.10.25])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i3KEITs24050;
	Tue, 20 Apr 2004 16:18:29 +0200 (MEST)
Message-ID: <40853135.9050804@eso.org>
Date: Tue, 20 Apr 2004 16:18:29 +0200
From: Alberto Micol <Alberto.Micol@eso.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pedro Osuna <posuna@iso.vilspa.esa.es>
CC: dal@ivoa.net, dm@ivoa.net, js@iso.vilspa.esa.es, po@iso.vilspa.esa.es,
   Christophe.Arviset@esa.int
Subject: Re: A note on a possible extension to SIAP
References: <200404191757.TAA22151@alinda.u-strasbg.fr> <1082467006.6351.216.camel@isol03.vilspa.esa.int>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Dear Pedro and Jesus,

>Dear Francois,
>
>this new approach, where you include different tables in the same
>RESOURCE  results, is closer to what we propose.
>
>Although we like it more than your previous proposal, we have been
>looking at the pros and cons of your approach vs ours, and these are the
>conclusions we have drawn. We think there is no-single solution for this
>issue, but also believe it is good to post these ideas to the whole
>community for discussion. Here they go:
>
>
>In your example, a table "points" to a structure which is outside itself
>(another table). This is to avoid modification of the DTD to allow
>tables inside tables. All the tables appear, therefore, at the same
>level.
>
>This means that the external tables do have to have an identifier to be
>able to do the joins among tables. 
>
>This would be an exact mapping of how an RDBMS works: independent tables
>joined through identifiers. 
>
>The problem with this approach is that it leaves the whole of the
>interpretation of the structure to the client. 
>  
>
I would rephrase it with:

The BEAUTY with this approach is that it leaves the whole of the
interpretation of the structure to the client.


>As the service is hiding the structure (it does not have any structure
>by itself, only pointers and identifiers to be able to do joins), the
>client will have to re-interpret it. In the case of a couple of
>observations, this could be done fast. In the case of hundreds of
>observations, in your approach the client would have to go through the
>whole results for each and every observation to figure out which
>exposures belong to it (and later, for each and every exposure to find
>the sources, etc.).
>
Do you really think that the typical SIAP user will want to receive back
thousands of images from his/her/its (the latter for a robotic client) 
query? (*)

Maybe I'm looking at things too much from a human user point of view here.
Probably because I cannot imagine too common use cases where it's a computer
using SIAP to retrieve huge lists of datasets, but I might be wrong. Maybe
the super-duper Registry/Portal will need that.

But if this is the case we  need first of all to clarify to ourselves 
what is the
main context for SIA, SSA, etc:

     Human Interaction or Computer Interoperability?

>
>As the results given in your way do not contain any specific ordering,
>the display client will have to make this ordering by itself.
>
Not by itself, but following the user's needs.

> This
>reordering would be done _without_ indexes (in the database terminology
>sense) and therefore would be a very un-efficient task. In our case,
>however, indexes are implicit in the structure itself, as
>"substructures" (as exposures, sources, etc.) are already inserted below
>a specific "superstructure" (like observation) and therefore the client
>only travels the structures once. 
>
Indeces are worth for tables with at least, let's say, 1000 records;
for smaller datasets a table scan is good enough; but go back to (*) above

>
>In our proposal, therefore, the join issues are handled at the server
>level, and the structure is already unveiled to the client, which would
>only have to display it in one go.
>
>  
>
It might reveal quite difficult to translate a complicated "data 
provider" structure
into what-and-how the user wants to see displayed (see Doug'a 
answer/experience).

>Another "artifact" of your proposal is the use of those "dummy"
>placeholders:
>
><TD>Exposure_Table</TD>
>
>These ones appear due to the fact that VOTable is imposing to have an
>entry per FIELD, and thus the <FIELD ID=Exposure_Table>, which in our
>case goes _inside_ the TABLE, has to have a dummy <TD> in your case as
>it points to an outside table. 
>
>This might look like cosmetics thing, but in our view it reveals an
>inconsistency between the VOTable real requirements and the way we would
>use the VOTables in your example. Of course, this problem would be
>solved by modifying somehow the DTD.
>
>As a last example we were trying to use to clarify our own ideas, we
>were identifying the structure we wanted to include in the SIAP to a
>file system directory structure. In our approach, we send the directory
>structure directly to the client, allowing it to display it the way it
>wants. In your approach, a very simple directory structure would be
>completely flat, with each subdirectory containing a pointer to the
>directory where it hangs from, allowing to "join" directories and
>subdirectories. Instead of giving the structure directly to the client,
>you give it the tools to create the structure, but then it is the client
>which has to do the whole process of "structurization". Although a valid
>approach, we believe that the time spent by the client in doing this
>should be spent by the server, which in the end is doing an asynchronous
>work with the rest of the servers being requested.
>
>
>Anyway, we believe this approach is much close to our idea of how things
>should work, and we think we are working towards a positive evolution
>for SIAP results. 
>  
>
Good!

>Best regards,
>P&J
>
Ciao,

Alberto


From owner-dal@eso.org  Tue Apr 20 17:55:06 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KFsk1U005689
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 20 Apr 2004 17:54:47 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3KFskA1005684
	for dal-outgoing; Tue, 20 Apr 2004 17:54:46 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KFsd1U005656;
	Tue, 20 Apr 2004 17:54:40 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3KFsXTY007594;
	Tue, 20 Apr 2004 17:54:34 +0200 (CEST)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i3KFsSc30520;
	Tue, 20 Apr 2004 09:54:28 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i3KFsRTU007581;
	Tue, 20 Apr 2004 09:54:27 -0600 (MDT)
Date: Tue, 20 Apr 2004 09:54:27 -0600 (MDT)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net, <dm@ivoa.net>
Subject: Summary of data representation issues
Message-ID: <Pine.LNX.4.44.0404200948570.15517-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.4, required 7,
	BAYES_01 -5.40, USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi Folks -

For what it's worth here is an attempt to summarize the state of the
data representation discussions (cribbed from the NVO QR).

	- Doug


6.2 Data representation (VOTable, etc.)
                                                                                
How best to represent science data in the VO is still a controversial
issue.  This continues to be discussed at length in the VOTable, DM,
and DAL forums without a clear consensus.  We have general agreement on
the following points:
                                                                                
    o   All data objects internal to the VO should have a formally defined
        data model.
                                                                                
    o   Data models should be defined independently of data representations.
        Multiple representations of the same data are permissible.
                                                                                
    o   XML in some form should be supported for data representation,
        although this should not be the only form of representation.
                                                                                
There appears to be a consensus on the following points although there may
still be some controversy:
                                                                                
    o   The specification of a data model should include a standard schema
        and serialization.  Data representations are not required to
        use either explicitly, but should be defined in terms of these,
        ideally with an explicit transformation, to allow data objects
        to be extracted from some arbitrary representation so that the
        objects could be verified with a schema or instantiated with some
        class code.
                                                                                
    o   FITS should continue to be used for transmission of bulk binary
        data, at least for the forseeable future.  In general we probably
        do not want to use FITS for metadata transport except as necessary
        to self-document a binary data element.
                                                                                
    o   VOTable should continue to be used with evolutionary enhancements,
        at least until there is some clearly better XML-based alternative.
                                                                                
The use of standard table mechanisms for the transmission of data objects
containing tabular data remains controversial.  Some believe that only
a native XML encoding should be used, to make it easier to implement
Web services and to make such data easier to process with XML tools.
Others believe that VOTable (or some comparable standard table mechanism)
should be used for tabular data in order to allow generic table-based
tools to be used upon such data.  Some believe that an "open" and easily
extensible document-centric approach using a generic container to hold
multiple component data models is required for datasets which are too
complex to describe with a single standard data model.


From owner-dal@eso.org  Tue Apr 20 18:37:08 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KGah1U010704
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 20 Apr 2004 18:36:44 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3KGahjl010703
	for dal-outgoing; Tue, 20 Apr 2004 18:36:43 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KGae1U010691;
	Tue, 20 Apr 2004 18:36:41 +0200 (MEST)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3KGaWXg020811;
	Tue, 20 Apr 2004 18:36:39 +0200 (CEST)
Received: from SARA (roy-nat.cacr.caltech.edu [131.215.144.149])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3KGaRk4029577
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Tue, 20 Apr 2004 09:36:27 -0700
Message-ID: <0b7301c426f5$ba39a700$0c0ba8c0@cacr.caltech.edu>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: "Alberto Micol" <Alberto.Micol@eso.org>
Cc: <dal@ivoa.net>, <dm@ivoa.net>, <js@iso.vilspa.esa.es>,
   <po@iso.vilspa.esa.es>, <Christophe.Arviset@esa.int>
References: <200404191757.TAA22151@alinda.u-strasbg.fr> <1082467006.6351.216.camel@isol03.vilspa.esa.int> <40853135.9050804@eso.org>
Subject: Re: A note on a possible extension to SIAP
Date: Tue, 20 Apr 2004 09:37:08 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

>      Human Interaction or Computer Interoperability?

Thank you Alberto, good question. In fact, maybe we could broaden the
question to the one we should start with -- What are the Use Cases for SIAP?

Here is one at least.

I have invested some time in building software that gets its data through
SIAP (Atlasmaker). I am worried that these new schemes will force me to do a
lot of recoding.

Currently, my code gets the VOTable response from the SIAP and looks for the
first table in the first resource. (Else fail).

In the table, it looks for the UCDs for RA, Dec, URL, and Format, and then
dereferences all the URLs that have the right values of RA, Dec, and Format.

Please Pedro and Francois, can you supply an alternate logic that I would
use if your schemes were to be accepted?

Roy

From owner-dal@eso.org  Tue Apr 20 20:53:03 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KIql1U025896
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 20 Apr 2004 20:52:48 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3KIqlZP025895
	for dal-outgoing; Tue, 20 Apr 2004 20:52:47 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KIqc1U025869;
	Tue, 20 Apr 2004 20:52:38 +0200 (MEST)
Received: from [134.171.76.3] (vpn-3.hq.eso.org [134.171.76.3])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i3KIqas02065;
	Tue, 20 Apr 2004 20:52:36 +0200 (MEST)
In-Reply-To: <0b7301c426f5$ba39a700$0c0ba8c0@cacr.caltech.edu>
References: <200404191757.TAA22151@alinda.u-strasbg.fr> <1082467006.6351.216.camel@isol03.vilspa.esa.int> <40853135.9050804@eso.org> <0b7301c426f5$ba39a700$0c0ba8c0@cacr.caltech.edu>
Mime-Version: 1.0 (Apple Message framework v613)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <E1ED30CB-92FB-11D8-A0E7-000A95D007D2@eso.org>
Content-Transfer-Encoding: 7bit
Cc: "<po@iso.vilspa.esa.es>" <po@iso.vilspa.esa.es>,
   "<dal@ivoa.net>" <dal@ivoa.net>,
   "<Christophe.Arviset@esa.int>" <Christophe.Arviset@esa.int>,
   "<js@iso.vilspa.esa.es>" <js@iso.vilspa.esa.es>
From: Alberto Micol <Alberto.Micol@eso.org>
Subject: Re: A note on a possible extension to SIAP
Date: Tue, 20 Apr 2004 20:52:33 +0200
To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mailer: Apple Mail (2.613)
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> Thank you Alberto, good question. In fact, maybe we could broaden the
> question to the one we should start with -- What are the Use Cases for 
> SIAP?

Well, I took for granted that a "Display Data Model", as sometimes the 
metadata tree is refer to,
is just only for Humans, and not for computers.

A Use Case for a SIAP (SSAP, etc) ?
Here is mine, which I think is a quite typical usage of the 
SIAP/metadata tree concept:

a user posts SIAP requests to MULTIPLE (multi-wavelength, multi-epoch, 
etc) data centers;
all answers get merged and end up displayed in ONE and the same 
metadata tree
structured according to user's defined criteria, for easy browsing.


It is going to be much easier, for the tool that assembles all the SIAP 
answers
into a metadata tree, to see one and the same structure, no matter 
which data center
originated it.

For this reason, my vote goes for a FLAT, but structured anyway, SIAP 
answer, a la CDS,
and not for a data-provider specific model.

Tony wrote:

> Please just choose the best one and use that - if you really must, 
> post a
> pointer in the other group but ask people not to reply to that.

... hence, I'm posting only to the DAL.

Alberto

From owner-dal@eso.org  Wed Apr 21 00:51:36 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KMpFBq019965
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 21 Apr 2004 00:51:15 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3KMpF9G019964
	for dal-outgoing; Wed, 21 Apr 2004 00:51:15 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KMpABq019958
	for <dal@ivoa.net>; Wed, 21 Apr 2004 00:51:10 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3KMp9TY021340
	for <dal@ivoa.net>; Wed, 21 Apr 2004 00:51:09 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3KMp5UI081351
          ; Wed, 21 Apr 2004 00:51:05 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id AAA00932;
	Wed, 21 Apr 2004 00:46:31 +0200 (MET DST)
Date: Wed, 21 Apr 2004 00:46:31 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404202246.AAA00932@alinda.u-strasbg.fr>
To: posuna@iso.vilspa.esa.es
Subject: Re: A note on a possible extension to SIAP
Cc: Christophe.Arviset@esa.int, dal@ivoa.net, js@iso.vilspa.esa.es,
   po@iso.vilspa.esa.es
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

    Dear Pedro and Jesus,

   I think in these conditions the best we have to do is to try
to build prototype interfaces for our proposals and demonstrate that
later to the group.

   By the way did you send your proposal to the VOTable group?
I suppose VOTable 1.1 is nearly accepted now.

Regards
François
    

SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Wed Apr 21 01:09:27 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KN9ABq021252
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 21 Apr 2004 01:09:11 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3KN9A4N021251
	for dal-outgoing; Wed, 21 Apr 2004 01:09:10 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3KN98Bq021246
	for <dal@ivoa.net>; Wed, 21 Apr 2004 01:09:08 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3KN94Xg003167
	for <dal@ivoa.net>; Wed, 21 Apr 2004 01:09:07 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i3KN91UI091868
          ; Wed, 21 Apr 2004 01:09:01 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id BAA00980;
	Wed, 21 Apr 2004 01:04:27 +0200 (MET DST)
Date: Wed, 21 Apr 2004 01:04:27 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200404202304.BAA00980@alinda.u-strasbg.fr>
To: Alberto.Micol@eso.org, roy@cacr.caltech.edu
Subject: Re: A note on a possible extension to SIAP
Cc: Christophe.Arviset@esa.int, dal@ivoa.net, js@iso.vilspa.esa.es,
   po@iso.vilspa.esa.es
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Roy,

   My answer is you could go on the same way.

   Both the VILSPA people and us tried to propose something backward
compatible with SIA 1.0 and I suppose SIA 1.1 .
   We remembered the "Keep it simple" you shouted in Strasbourg DAL
meeting.

   Let's say the kind of stuff we are proposing belongs to  a
   SIA 2:
    SIA 2 interfaces will have to interpret both SIA 1 and SIA 2

    SIA 1 interfaces will find in SIA 2  a standard first table (except a few
"free" new fields) and will just have to ignore the remaining tables
and resources.

    Many people think we need more structure coming from data models
in DAL (see Alberto's answer for example)

 The only alternative to making SIA evoluate in the future is to define
a new more general DAL protocol (Doug suggested GIA for that).

Cheers 
François

SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Wed Apr 21 15:57:53 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3LDvPBq006024
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 21 Apr 2004 15:57:26 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i3LDvPOO006023
	for dal-outgoing; Wed, 21 Apr 2004 15:57:25 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i3LDvMBq006009;
	Wed, 21 Apr 2004 15:57:22 +0200 (MEST)
Received: from esacom51.vilspa.esa.int (esacom51-ext.vilspa.esa.int [192.171.2.19])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i3LDvKXe002425;
	Wed, 21 Apr 2004 15:57:20 +0200 (CEST)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id i3LDv5dS003776;
	Wed, 21 Apr 2004 15:57:05 +0200 (MET DST)
Received: from isol03.vilspa.esa.int (isol03.vilspa.esa.int [193.147.153.17])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i3LDuxW3007917;
	Wed, 21 Apr 2004 15:56:59 +0200 (MEST)
Subject: Re: A note on a possible extension to SIAP
From: Pedro Osuna <posuna@iso.vilspa.esa.es>
To: Roy Williams <roy@cacr.caltech.edu>
Cc: Alberto Micol <Alberto.Micol@eso.org>, dal@ivoa.net, js@iso.vilspa.esa.es,
   po@iso.vilspa.esa.es, Christophe.Arviset@esa.int
In-Reply-To: <0b7301c426f5$ba39a700$0c0ba8c0@cacr.caltech.edu>
References: <200404191757.TAA22151@alinda.u-strasbg.fr>
	 <1082467006.6351.216.camel@isol03.vilspa.esa.int>
	 <40853135.9050804@eso.org>
	 <0b7301c426f5$ba39a700$0c0ba8c0@cacr.caltech.edu>
Content-Type: text/plain
Message-Id: <1082555818.6351.397.camel@isol03.vilspa.esa.int>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) 
Date: Wed, 21 Apr 2004 15:56:58 +0200
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Pedro Osuna <posuna@iso.vilspa.esa.es>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Roy,

> Please Pedro and Francois, can you supply an alternate logic that > I
would use if your schemes were to be accepted?

We would still keep an image CDATA pointer in our "top level" structure;
this means that if you would be using our service, you would not have to
modify your code at all: you just stay at the highest (let's say, the
"flattest") level in our hierarchy, and that's it, you stop there.

On the other hand, I believe that in the process of building a whole VO,
having to change our code will be a common task for everyone. 

With respect to a use case that would require some structure, I have
one, coming from the AVO demo, that clearly illustrates the point: 

- guess whether a Young Stellar Object is  of type I or II.

In this use case, images in different X-Ray bands should be used, as
YSOs of different types emit in different X-Ray regions. You can check
this use case at:

http://www.euro-vo.org/twiki/bin/view/Avo/XMMUseCases


With respect to how much "beautiful" a flat structure is as opposed to a
structure where each data is identified and structured in the display, I
have my doubts as -fortunately- beauty is quite a subjective thing.

Cheers,
P.



On Tue, 2004-04-20 at 18:37, Roy Williams wrote:
> >      Human Interaction or Computer Interoperability?
> 
> Thank you Alberto, good question. In fact, maybe we could broaden the
> question to the one we should start with -- What are the Use Cases for SIAP?
> 
> Here is one at least.
> 
> I have invested some time in building software that gets its data through
> SIAP (Atlasmaker). I am worried that these new schemes will force me to do a
> lot of recoding.
> 
> Currently, my code gets the VOTable response from the SIAP and looks for the
> first table in the first resource. (Else fail).
> 
> In the table, it looks for the UCDs for RA, Dec, URL, and Format, and then
> dereferences all the URLs that have the right values of RA, Dec, and Format.
> 
> Please Pedro and Francois, can you supply an alternate logic that I would
> use if your schemes were to be accepted?
> 
> Roy
-- 
Pedro Osuna Alcalaya

 
Software Engineer
VILSPA Archive Development Team
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314
                                                                                
European Space Agency
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


From owner-radiovo@eso.org  Tue May 11 13:37:44 2004
Return-Path: <owner-radiovo@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4BBbU5t019478
	for <radiovo-outgoing@mercury.hq.eso.org>; Tue, 11 May 2004 13:37:31 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4BBbU1m019477
	for radiovo-outgoing; Tue, 11 May 2004 13:37:30 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-radiovo@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4BBbH5t019446;
	Tue, 11 May 2004 13:37:17 +0200 (MEST)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4BBbGXe004176;
	Tue, 11 May 2004 13:37:16 +0200 (CEST)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1BNVZU-0005im-28; Tue, 11 May 2004 12:37:16 +0100
Received: from [130.88.24.146] (helo=megahard)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1BNVZT-0002yI-00; Tue, 11 May 2004 12:37:15 +0100
Date: Tue, 11 May 2004 12:37:11 +0100 (BST)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@megahard
To: radiovo@ivoa.net
cc: dm@ivoa.net, dal@ivoa.net
Subject: Radio data providers
Message-ID: <Pine.GSO.4.53.0405111234470.24952@megahard>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BNVZU-0005im-28*OiWyXn/9hLg*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-radiovo@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


Dear all,

I have posted a summary of the replies to the radio data providers
questionnaire at
http://www.ivoa.net/twiki/bin/view/IVOA/IVOADMInterferometryWP

along with a link to RadioNet etc.

NB this is cross-posted as the links cover a range of information, however
if you reply please reply only to the relevant forum!

thanks

Anita

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).

From owner-dal@eso.org  Thu May 13 05:54:09 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4D3rZff023278
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 13 May 2004 05:53:35 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4D3rZTN023276
	for dal-outgoing; Thu, 13 May 2004 05:53:35 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4D3rVff023268
	for <dal@ivoa.net>; Thu, 13 May 2004 05:53:32 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4D3rTTY021451
	for <dal@ivoa.net>; Thu, 13 May 2004 05:53:30 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i4D3rLSb024171;
	Wed, 12 May 2004 21:53:22 -0600
Date: Wed, 12 May 2004 21:53:16 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: dal@ivoa.net
Subject: Proposed agenda for DAL session at the May Interop meeting
Message-ID: <Pine.LNX.4.44.0405122149430.1254-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear DAL folks -

The Data Access Layer discussions will be held 08:30 - 12:00 Tuesday and
Wednesday mornings, May 25-26, in Jefferson room 256.  We may also try
to have some smaller impromptu focus meetings during the week to work
out details of the interfaces currently in the definition stage.

What follows is a draft agenda for the DAL sessions with some suggested
topics in each area.  If you would like to suggest a new topic or contribute
in any of these areas please let me know.  Those of you who have actively
worked to develop specific material in the past six months are encouraged
to present the relevant topic.  The time allocations will be determined
later as the agenda is developed.

Any comments or other suggestions are most welcome!

    - Doug


1. SSA, time series
    - Service classes
    - Query interface
    - SSA data model
    - Data representation (VOTable, FITS, XML, text)

    We are still working on the SSA interface and data model documents
    and hope to have these available in advance of the workshop.

2. SIA V1.1
    - General dataset metadata (identification, characterization)
    - Logical dataset identifer proposal (logical groupings)
    - Ranking proposal
    - UCD normalization is discussed separately; see below
    - Anything else?

    SIA V1.1 is a limited scope upgrade to the current interface.  The goal
    is the bring the interface up to current standards and add some modest
    new capabilities.

3. UTYPE and UCD (Joint with UCD WG!)
    - When and how to use UCD, UTYPE
    - UCDs for SIA V1.1

    This topic has received a great deal of discussion over the past year.
    Maybe this time we can nail it down, at least as regards usage in
    SIA V1.1, and SSA, which will follow the same pattern.

4. Roadmap and Future Topics
    - Catalog access (plans for ADQL usage in DAL, updated catalog access)
    - Exanded image access capabilities
    - Interferometry and event data
    - Other

    What is required to support the applications we plan to build over
    the next year?


From owner-apps@eso.org  Thu May 13 22:52:36 2004
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4DKqKeo013598
	for <apps-outgoing@mercury.hq.eso.org>; Thu, 13 May 2004 22:52:21 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4DKqKjn013597
	for apps-outgoing; Thu, 13 May 2004 22:52:20 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4DKqHeo013593;
	Thu, 13 May 2004 22:52:17 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4DKqEXe001498;
	Thu, 13 May 2004 22:52:15 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i4DKq7Sb002124;
	Thu, 13 May 2004 14:52:07 -0600
Date: Thu, 13 May 2004 14:52:04 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: apps@ivoa.net, <dal@ivoa.net>
Subject: Re: Putting the pieces together...
In-Reply-To: <40A394E2.2010900@lheapop.gsfc.nasa.gov>
Message-ID: <Pine.LNX.4.44.0405131425080.1254-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

(I am moving my response to this to DAL since this is mainly a discussion
of SSA).

Hi Tom -

This is an excellent way of looking at the problem of how we actually
use the VO in a typical data analysis scenario.  At this level we have
three main elements:

    o	User application (VSPlot).
    o	Registry.
    o	DAL Service (SSA).

Most of the functionality you identify on the VO side is provided by SSA.
This is what SSA is all about - making it possibly to write actual data
real world analysis applications that access spectral data via the VO.

On the data modeling side the key thing here is the SSA data model.  While
the goal is to keep this "simple" (focused only on one class of data,
limited to 1D spectra, etc.) it also needs to be real enough to actually
be useful, e.g., define a useful set of spectral coordinate types, flux
vector types, deal with background, errors, and so forth.

On the DM side, we can provide something useful for actual data analysis
given only the SSA data model.  Already though things start to emerge
which we would like so standardize more broadly, e.g., data provenance,
data characterization (part of what is currently called the "observation"
data model).  This is a good way to develop things: start with something
useful that actually works end-to-end, and as the technology develops,
refine it to include more sophisticated standard query facilities,
standardized component data models and metadata, etc.

Regarding data coming back from various sources: data providers should
be strongly encouraged to implement services that return data in the
service-defined data model.  Since most data has to be reformatted anyway
this won't be that hard to do.  Applications will probably use the registry
to select only services which are capable of returning data in a format
defined by the SSA protocol (SSAP).  These formats all implement the SSA
data model.

Ivo - regarding your point about data quality vectors:  As you know,
the SSA data model has a data quality vector.  We don't really know what
to put in it though.  I don't think we should put anything instrumental
in nature in the general SSA data model (this can be done but it would
go into nonstandard extension records).  Simple models for the quality
vector would be binary (good or bad) or trinary (known good, known bad
or flagged, or questionable).  Perhaps once we get more experience with
real data from archives it will be possible to develop a more refined
quality model.  (Note this should not be confused with the error vectors
which we already have).

	- Doug



On Thu, 13 May 2004, Thomas McGlynn wrote:

> [Mail note.  I've sent this to the DM and APPS groups, it's
> relevant to others, but I don't want to get 5 copies of
> every response.]
> 
> There has certainly been plenty of mail on data models, registries,
> STC, UCD's, UTYPE's, measurements, etc, but a lot of it is
> frustrating for me.  I can't seem to get a hold on how much of it
> gets used and what the consequences in terms of what the
> developer or user sees will be.  We seem to spend a lot of
> time discussing abstract data and data structures, but there
> has been very little about how software finds and uses this information.
> 
> Until these discussions are anchored in some more concrete framework
> for how the data models, UTYPES, STC are used, it may
> be very difficult to come to any real consensus on what
> they should look like.
> 
> Below I go through an extended example which shows how I think
> we might use many of the concepts that have been the
> subject of discussion.  It's clear to me that there are enormous
> largely undiscussed gaps between these data concepts and
> their use in software.
> 
> 
> ------------------------------------------------------------------
> Scenario:
> 
> Find and plot spectra of TY Pyxis in the range from the soft X-ray
> to the optical (1 A to 10000 A). Let's call the software tool
> that does this VSPlot.
> 
> Step 1.
> 
> VSPlot needs to know the location of at least one registry.
> VSPlot makes a query of the registry using a standard registry protocol.
> VSPlot asks for all SSAP services that might have data in the desired
> regimes and location.
> 
>    Issue 1.A: Is the registry query syntax different from the VOQL protocol?
>    If so what is it?
> 
>    Issue 1.B: What is the protocol for the registry query?  Is it defined
>    as by some standard registry WSDL?
> 
>    Issue 1.C: VSPlot hardwires the connection between spectra and SSAP services.
>    Are we restricted to a single kind of service for each kind of data?  Do
>    we need to register the attributes of the kinds of services so that if I'm
>    interested in getting archival spectral data I might learn that there are SSA
>    services and maybe other kinds of services that I want to query?
> 
>    Issue 1.D: How does VSPlot know where the registry is?  Is there a registry
>    of registries?  What is the root of the hierarchy?
> 
> Step 2.
> 
> VSPlot parses the set of services returned from the registry?
> 
>    Issue 2.A: Where is the structure/protocol of this returned data defined?
> 
>    Issue 2.B: What is the contract regarding these services?  (I.e.,
>    given that I asked for services that meet some criteria (spectral
>    and spactial coverage), do I know that these services will actually
>    have data that meets these criteria?  Probably not I think.)
> 
>    Issue 2.C: How much information is stored in the registry
>    about each of the SSA services?
> 
> Step 3.
> 
> VSPlot queries the potential matching service one at a time to
> get links to candidate spectral data using the SSA protocol.
> 
>    Issue 3. Need definition of the SSA protocol.
> 
> Step 4.
> 
> VSPlot now has a links to a list of files that may be of interest
> for plotting.  We begin a loop over this list.
> 
> VSPlot copies a spectral file into local storage.
> 
> Step 5.
> 
> VSPlot determines if the file supports the Spectrum data model.
> If the file does not support this data model it is discarded.
> 
>    Issue 5.A:  How do we find out if a data element supports a given
>    data model?  Is it required that any file returned by the SSA
>    support the Spectrum data model?  If so where do we put the mapping
>    between service types and the data models that the returned
>    data is going to support?
> 
>    Issue 5.B: Is there some list of the potential data models that
>    any file might support?
> 
> Step 6.
> 
> VSPlot looks for frame information for this file to confirm
> that it is a spectrum at the appropriate location and in the appropriate
> spectral regime for further processing.
> 
>    Issue 6.A For a FITS file I know how to do this.  I'm much less
>    clear how to do this for arbitrary data returned by an SSA service.
>    Is this a standard method associated with the Spectrum data
>    model that enables me to find this out?  Basically we're asking
>    how we discover the STC information for a given dataset and the
>    comparable spectral info.
> 
>    Issue 6.B Is coverage information (spatial and spectral) required to be
>    in a standard format?  If so what is that format?  If not do we have
>    standard conversion services or is it the responsibility of the application
>    to convert?
> 
> Step 7.
> 
> VSPlot iteratively uses the standard (in this scenario) getNextElement method defined
> in the spectrum data model to extract data from the file.
> 
>    Issue 7.A  How do we use the data model in real code?  Is the
>    data model associated with a set of Java classes that we can
>    invoke on the data?  If the data model is more than documentation
>    we need to be able to instantiate behavior in some TBD way.
>    How do we preserve language independence? (Or do we?)
> 
>    Issue 7.B Does the data model describe behavior that is defined
>    for the data element or does it indicate that the data is convertible
>    to some fiducial form?  If the latter who is responsible for the conversion?
> 
> 
> Step 8.
> 
> The user had indicated that they wanted the spectrum to be flux versus
> wavelength.  VSPlot needs to see if it can convert the data extracted
> from the file into those units.  VSPlot looks at the UCDs and Units
> associated with the spectra.  It converts columns to the desired
> units where possible.  Spectra where the data are not convertable
> are discarded.
> 
>    Issue 8.A. How does VSPlot know which column to look at as the flux-like
>    column and which as the wavelength-like column?  It could look through
>    a list of potential UCD's or UTYPE's could be invoked here.   Could
>    the UCD and UTYPE seem to conflict?
> 
>    Issue 8.B.  How do we do the transformations? Is this VSPlot's responsibility
>    or do we support standard VO transformation services.
> 
>    Issue 8.C.  This is a hard step.  How does VSPlot know enough to distinguish
>    between raw and background subtracted spectra and the myriad details like that?
>    Is this a characeristic of the flux column or of the entire spectral file?
>    This seems to be where all of the discussion of measurements and quantities
>    needs to provide some benefit to the user.
> 
>    Issue 8.D. How does VSPlot find and use the measurement data model
>    information to help here?  What functionality is associated
>    with a measurement?
> 
> 
> Step 9.
> 
> The data is searched for error columns using UCDs and errors bars are computed.
> 
>    Issue 9.A. Errors need to be transformed if the data is transformed, but
>    the transformations can be complex.  Where is this handled?
> 
>    Issue 9.B.  How do we aasociate the error columns with the approprite
>    measurements?  Again this seems to be part of the mesurement discussion
>    but I need to know how this model is instantiated for it to be useful.
>    Does it use Groups in VOTables?  Are there other mechanisms?
> 
> 
> Step 10.
> 
> The data and errors are plotted.  Fini!
> 
> -----------------------------------------------------------
> 
> This is intended to give only an example of how these
> pieces might play together.  I don't know that there is any more
> formal description of this architecture -- nor do I know
> who is responsible for one.  Without such a broader picture
> of how all these things interact it's very difficult
> to assess all the myriad proposals that show
> up in the mail.
> 
> The issues seem to repeat two themes:
> 
> How do I find and get the various data structures that we've
> been talking about?
> What functionality is associated with them?  If we're talking
> about data models as objects, then what are the methods as
> well as the fields?
> 
> 
> If we can focus on what we really want to use the quantity
> model for, or the UTYPEs, or the spectral data model, then I think
> we'll be a lot more successful at defining them -- and we'll make
> a lot of progress towards deliverable VO applications!
> 
> The places where we've been most successful in the VO are when
> we have balanced definition of structures with protocols for using
> these structures: e.g., VOTables, UCDs and CGI access in the SIAP.
> 
> 		Regards,
> 		Tom McGlynn
> 
> 
> 

From owner-apps@eso.org  Fri May 14 14:46:06 2004
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4ECjkRL002724
	for <apps-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 14:45:47 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4ECjkKv002722
	for apps-outgoing; Fri, 14 May 2004 14:45:46 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4ECjgRL002704;
	Fri, 14 May 2004 14:45:43 +0200 (MEST)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4ECjeTY015952;
	Fri, 14 May 2004 14:45:41 +0200 (CEST)
Received: from stsci.edu (obiwan.stsci.edu [130.167.236.123])
	by donner.stsci.edu (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ALG40272;
	Fri, 14 May 2004 08:45:37 -0400 (EDT)
Message-ID: <40A4BF76.BB004126@stsci.edu>
Date: Fri, 14 May 2004 08:45:42 -0400
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Doug Tody <dtody@nrao.edu>
CC: apps@ivoa.net, dal@ivoa.net
Subject: Re: Putting the pieces together...
References: <Pine.LNX.4.44.0405131425080.1254-100000@lepus.tuc.noao.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Junkmail-Whitelist: YES (by domain whitelist at donner.stsci.edu)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Ivo Busko <busko@stsci.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000



Doug Tody wrote:
<snip>
> Ivo - regarding your point about data quality vectors:  As you know,
> the SSA data model has a data quality vector.  We don't really know what
> to put in it though.  I don't think we should put anything instrumental
> in nature in the general SSA data model (this can be done but it would
> go into nonstandard extension records).  Simple models for the quality
> vector would be binary (good or bad) or trinary (known good, known bad
> or flagged, or questionable).  Perhaps once we get more experience with
> real data from archives it will be possible to develop a more refined
> quality model.  (Note this should not be confused with the error vectors
> which we already have).
> 
>         - Doug

Thanks, Doug, that sounds good enough. I agree that nothing
instrument-specific
should be put in the data model. However, something must be done to
accomodate
cases that do not follow the norm.

I have in mind cases where a binary or trinary model wouldn't be enough
to summarize the data quality information available in the original
file. 
A good example is FUSE data; it uses a continuously variable 2-byte
integer
value to store a kind of "weight" (between 0 an 100), instead of the
more
commonly found bit-encoded mask. To cast that data into a, say, binary
good/bad
model, one needs an additional piece of information, in the form of a
threshold
value. 

Ideally, a VO transaction involving such data should allow for the
threshold
value to be either specified by the requestor, or alternatively be set
by the
data provider in a instrument-dependent way. 

In short, my point is: shouldn't the data model allow some room for
non-standard
extra bits of info such as data quality threshold values?

Cheers,

-Ivo

From owner-dal@eso.org  Fri May 14 15:15:18 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EDErRL006603
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 15:14:53 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4EDEr9v006598
	for dal-outgoing; Fri, 14 May 2004 15:14:53 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EDEkRL006566
	for <dal@ivoa.net>; Fri, 14 May 2004 15:14:46 +0200 (MEST)
Received: from katrine.roe.ac.uk (katrine.roe.ac.uk [195.194.120.81])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4EDEiXe026058
	for <dal@ivoa.net>; Fri, 14 May 2004 15:14:44 +0200 (CEST)
Received: from katrine.roe.ac.uk (localhost [127.0.0.1])
	by katrine.roe.ac.uk (Postfix) with ESMTP
	id 82449441C0; Fri, 14 May 2004 14:14:44 +0100 (BST)
Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP
	id 1784; Fri, 14 May 2004 14:14:43 +0100 (BST)
Received: from katrine (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP
	id 26F15441BC; Fri, 14 May 2004 14:14:43 +0100 (BST)
Received: from localhost ([127.0.0.1])
	by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ;
	Fri, 14 May 2004 14:14:43 +0100 (BST)
Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180])
	by katrine.roe.ac.uk (Postfix) with ESMTP
	id F07C7441BC; Fri, 14 May 2004 14:14:42 +0100 (BST)
Received: from localhost (localhost [[UNIX: localhost]])
	by fannich.roe.ac.uk (8.11.6/8.9.1) id i4EDEgh29487;
	Fri, 14 May 2004 14:14:42 +0100
Message-Id: <200405141314.i4EDEgh29487@fannich.roe.ac.uk>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Martin Hill <mch@roe.ac.uk>
Organization: ROE
To: Ivo Busko <busko@stsci.edu>, Doug Tody <dtody@nrao.edu>
Subject: Re: Putting the pieces together - Quality...
Date: Fri, 14 May 2004 14:14:42 +0100
X-Mailer: KMail [version 1.3.2]
Cc: dal@ivoa.net
References: <Pine.LNX.4.44.0405131425080.1254-100000@lepus.tuc.noao.edu> <40A4BF76.BB004126@stsci.edu>
In-Reply-To: <40A4BF76.BB004126@stsci.edu>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk
X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no 
	version=2.62
X-Spam-Level: 
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Martin Hill <mch@roe.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

The data model would be the wrong place to put non-standard things :-)

Quality threshold values I would have thought would be set by the datacenters 
- after all, these are the people who have already set effective threshold 
values when working out binary or trinary quality values. Later we can model 
quality more carefully.

Which brings us to another point; if we can model the quality of an 
individual bit of data, how do we model quality on large groups such as 
datasets?  Presumably some datasets are better than others, and so the data 
'as a whole' has better value than another one - particularly as I understand 
it even undergraduates should be able to post their data on the VO in order 
to use VO tools, and to allow other people to use their data :-).

Cheers,

Martin

On Friday 14 May 2004 1:45 pm, Ivo Busko wrote:
> Doug Tody wrote:
> <snip>
>
> > Ivo - regarding your point about data quality vectors:  As you know,
> > the SSA data model has a data quality vector.  We don't really know what
> > to put in it though.  I don't think we should put anything instrumental
> > in nature in the general SSA data model (this can be done but it would
> > go into nonstandard extension records).  Simple models for the quality
> > vector would be binary (good or bad) or trinary (known good, known bad
> > or flagged, or questionable).  Perhaps once we get more experience with
> > real data from archives it will be possible to develop a more refined
> > quality model.  (Note this should not be confused with the error vectors
> > which we already have).
> >
> >         - Doug
>
> Thanks, Doug, that sounds good enough. I agree that nothing
> instrument-specific
> should be put in the data model. However, something must be done to
> accomodate
> cases that do not follow the norm.
>
> I have in mind cases where a binary or trinary model wouldn't be enough
> to summarize the data quality information available in the original
> file.
> A good example is FUSE data; it uses a continuously variable 2-byte
> integer
> value to store a kind of "weight" (between 0 an 100), instead of the
> more
> commonly found bit-encoded mask. To cast that data into a, say, binary
> good/bad
> model, one needs an additional piece of information, in the form of a
> threshold
> value.
>
> Ideally, a VO transaction involving such data should allow for the
> threshold
> value to be either specified by the requestor, or alternatively be set
> by the
> data provider in a instrument-dependent way.
>
> In short, my point is: shouldn't the data model allow some room for
> non-standard
> extra bits of info such as data quality threshold values?
>
> Cheers,
>
> -Ivo

-- 
Martin Hill
Astrogrid/AVO, ROE
Tel: 07901 55 24 66

From owner-dal@eso.org  Fri May 14 15:45:46 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EDjTRL011159
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 15:45:29 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4EDjTNW011158
	for dal-outgoing; Fri, 14 May 2004 15:45:29 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EDjJRL011128;
	Fri, 14 May 2004 15:45:19 +0200 (MEST)
Received: from milkyway.gsfc.nasa.gov (lheapop.gsfc.nasa.gov [128.183.16.62])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4EDjFXe027456;
	Fri, 14 May 2004 15:45:15 +0200 (CEST)
Received: from lheapop.gsfc.nasa.gov (silk3.gsfc.nasa.gov [128.183.18.68])
	by milkyway.gsfc.nasa.gov (8.12.10/8.12.10) with ESMTP id i4EDjEM0012237;
	Fri, 14 May 2004 09:45:14 -0400
Message-ID: <40A4CD8A.80208@lheapop.gsfc.nasa.gov>
Date: Fri, 14 May 2004 09:45:46 -0400
From: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Doug Tody <dtody@nrao.edu>
CC: apps@ivoa.net, dal@ivoa.net
Subject: Re: Putting the pieces together...
References: <Pine.LNX.4.44.0405131425080.1254-100000@lepus.tuc.noao.edu>
In-Reply-To: <Pine.LNX.4.44.0405131425080.1254-100000@lepus.tuc.noao.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-Scanned-By: MIMEDefang 2.42
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Thomas McGlynn <tam@lheapop.gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Doug Tody wrote:
> (I am moving my response to this to DAL since this is mainly a discussion
> of SSA).
> 
> Hi Tom -
> 
> This is an excellent way of looking at the problem of how we actually
> use the VO in a typical data analysis scenario.  At this level we have
> three main elements:
> 
>     o	User application (VSPlot).
>     o	Registry.
>     o	DAL Service (SSA).
> 
> Most of the functionality you identify on the VO side is provided by SSA.
> This is what SSA is all about - making it possibly to write actual data
> real world analysis applications that access spectral data via the VO.
> 
> On the data modeling side the key thing here is the SSA data model.  While
> the goal is to keep this "simple" (focused only on one class of data,
> limited to 1D spectra, etc.) it also needs to be real enough to actually
> be useful, e.g., define a useful set of spectral coordinate types, flux
> vector types, deal with background, errors, and so forth.
> 
> On the DM side, we can provide something useful for actual data analysis
> given only the SSA data model.  Already though things start to emerge
> which we would like so standardize more broadly, e.g., data provenance,
> data characterization (part of what is currently called the "observation"
> data model).  This is a good way to develop things: start with something
> useful that actually works end-to-end, and as the technology develops,
> refine it to include more sophisticated standard query facilities,
> standardized component data models and metadata, etc.
>
....
Hi Doug,

I'm less concerned about the SSAP itself (other than time
it is taking to get an actual SSAP document to work with).  The SSA does
address both structures and protocols.  So I'm reasonably confident
that using the SSA I'll be able to find and extract spectral
data files from providers.  I have a good sense of the kind of
code I'm going to write in that area.


But the SSA doesn't say beans about using the spectra. What does it mean
to say that we have an SSA data model? Is that different from the
spectrum data model?  What does it mean to have any data model in terms
of the software I'm going to write?  I don't think it means that all
of the data files are in the same format.  Or does it?  Does it mean
that there is some standard software package that can read these data?
How do these quantity and measurement models fit in? Do these things mean the
the data provider has provided a suite of tools that
can access files or columns with tables?  Presumably I can <use> the
data model in some way but I don't have a clue how.

As a developer of a piece of software that's going to try to plot
spectra that 'have' the spectral data model, I need to write code that
gets information from the files.  How does the data model help me
do that?  I mean this not in some abstract sense of organizing concepts
but understanding the lines of code I might write.

I'm not suggesting that data models, UTYPEs, UCDs and all of this
aren't useful, but that the discussion of them has focused so much
on the underlying abstractions in the data, that how they
connect with and are used in VO applications is completely opaque,
at least to me.   Personally I suspect that if we had some more concrete
sense of how these data elements and structures were going to
be used we'd have a lot easier time defining what they should look like.



	Regards,
	Tom


From owner-dm@eso.org  Fri May 14 19:32:02 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EHVeRL007422
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 19:31:41 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4EHVetb007420
	for dm-outgoing; Fri, 14 May 2004 19:31:40 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EHVaRL007413;
	Fri, 14 May 2004 19:31:37 +0200 (MEST)
Received: from katrine.roe.ac.uk (katrine.roe.ac.uk [195.194.120.81])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4EHVZTY027048;
	Fri, 14 May 2004 19:31:35 +0200 (CEST)
Received: from katrine.roe.ac.uk (localhost [127.0.0.1])
	by katrine.roe.ac.uk (Postfix) with ESMTP
	id 35B23441F5; Fri, 14 May 2004 18:31:35 +0100 (BST)
Received: from somehost by katrine.roe.ac.uk (postfixilter 1.4) with SMTP
	id 14047; Fri, 14 May 2004 18:31:34 +0100 (BST)
Received: from katrine (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP
	id E206E441F7; Fri, 14 May 2004 18:31:33 +0100 (BST)
Received: from localhost ([127.0.0.1])
	by katrine.roe.ac.uk (MailMonitor for SMTP v1.2.2 ) ;
	Fri, 14 May 2004 18:31:33 +0100 (BST)
Received: from fannich.roe.ac.uk (fannich.roe.ac.uk [195.194.120.180])
	by katrine.roe.ac.uk (Postfix) with ESMTP
	id B188D441F7; Fri, 14 May 2004 18:31:33 +0100 (BST)
Received: from localhost (localhost [[UNIX: localhost]])
	by fannich.roe.ac.uk (8.11.6/8.9.1) id i4EHVXb29761;
	Fri, 14 May 2004 18:31:33 +0100
Message-Id: <200405141731.i4EHVXb29761@fannich.roe.ac.uk>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Martin Hill <mch@roe.ac.uk>
Organization: ROE
To: dm@ivoa.net, dal@ivoa.net
Subject: Serialisation
Date: Fri, 14 May 2004 18:31:33 +0100
X-Mailer: KMail [version 1.3.2]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on katrine.roe.ac.uk
X-Spam-Status: No, hits=0.0 required=1000.0 tests=none autolearn=no 
	version=2.62
X-Spam-Level: 
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Martin Hill <mch@roe.ac.uk>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Would it be worth starting a new discussion group, say dataform@ivoa.net or 
serialisation@ivoa.net (or rather serialization :-) as it seems to involve 
data access and data modelling and apps but not completely so? 

-- 
Martin Hill
Astrogrid/AVO, ROE
Tel: 07901 55 24 66

From owner-dal@eso.org  Fri May 14 20:27:14 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EIQrRL012477
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 20:26:53 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4EIQrSZ012476
	for dal-outgoing; Fri, 14 May 2004 20:26:53 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EIQmRL012442;
	Fri, 14 May 2004 20:26:48 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4EIQjTY028856;
	Fri, 14 May 2004 20:26:46 +0200 (CEST)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i4EIQbN16949;
	Fri, 14 May 2004 12:26:37 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i4EIQZTU007972;
	Fri, 14 May 2004 12:26:36 -0600 (MDT)
Date: Fri, 14 May 2004 12:26:35 -0600 (MDT)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: Ivo Busko <busko@stsci.edu>
cc: apps@ivoa.net, <dal@ivoa.net>
Subject: Re: Putting the pieces together...
In-Reply-To: <40A4BF76.BB004126@stsci.edu>
Message-ID: <Pine.LNX.4.44.0405141216320.15810-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7,
	BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37,
	QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Ivo -

Having a uniform quality metric such as 0-1.0 or 0-100 is a good idea,
that would work too and seems general enough.  Again, it would be useful
to survey what is actually done currently in spectral archives then we
could be sure what we come up with is reasonable.

> In short, my point is: shouldn't the data model allow some room for
> non-standard extra bits of info such as data quality threshold values?

This sounds like what I meant by extension records.  At the level of a
dataset I think we should always allow "nonstandard" extensions which extend
the core model using the same mechanisms as used in the core.  In many
cases this just means adding some extra keywords, which is probably how
one would encode a threshold value.  Or this extra information could take
the form of additional structured entities in the dataset.  Of course it
would take extra work to make use of such information, but I think many
would like to have such information available even if it is not yet
standardized, so long as it does not obscure the core model.

	- Doug



On Fri, 14 May 2004, Ivo Busko wrote:

> 
> Doug Tody wrote:
> <snip>
> > Ivo - regarding your point about data quality vectors:  As you know,
> > the SSA data model has a data quality vector.  We don't really know what
> > to put in it though.  I don't think we should put anything instrumental
> > in nature in the general SSA data model (this can be done but it would
> > go into nonstandard extension records).  Simple models for the quality
> > vector would be binary (good or bad) or trinary (known good, known bad
> > or flagged, or questionable).  Perhaps once we get more experience with
> > real data from archives it will be possible to develop a more refined
> > quality model.  (Note this should not be confused with the error vectors
> > which we already have).
> > 
> >         - Doug
> 
> Thanks, Doug, that sounds good enough. I agree that nothing
> instrument-specific
> should be put in the data model. However, something must be done to
> accomodate
> cases that do not follow the norm.
> 
> I have in mind cases where a binary or trinary model wouldn't be enough
> to summarize the data quality information available in the original
> file. 
> A good example is FUSE data; it uses a continuously variable 2-byte
> integer
> value to store a kind of "weight" (between 0 an 100), instead of the
> more
> commonly found bit-encoded mask. To cast that data into a, say, binary
> good/bad
> model, one needs an additional piece of information, in the form of a
> threshold
> value. 
> 
> Ideally, a VO transaction involving such data should allow for the
> threshold
> value to be either specified by the requestor, or alternatively be set
> by the
> data provider in a instrument-dependent way. 
> 
> In short, my point is: shouldn't the data model allow some room for
> non-standard
> extra bits of info such as data quality threshold values?
> 
> Cheers,
> 
> -Ivo
> 
> 

From owner-dal@eso.org  Fri May 14 20:34:52 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EIYTRL014212
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 20:34:29 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4EIYThD014211
	for dal-outgoing; Fri, 14 May 2004 20:34:29 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EIYPRL014201
	for <dal@ivoa.net>; Fri, 14 May 2004 20:34:26 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4EIYNXe007663
	for <dal@ivoa.net>; Fri, 14 May 2004 20:34:24 +0200 (CEST)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i4EIYJN17617;
	Fri, 14 May 2004 12:34:19 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i4EIYGTU009024;
	Fri, 14 May 2004 12:34:17 -0600 (MDT)
Date: Fri, 14 May 2004 12:34:16 -0600 (MDT)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: Martin Hill <mch@roe.ac.uk>
cc: Ivo Busko <busko@stsci.edu>, <dal@ivoa.net>
Subject: Re: Putting the pieces together - Quality...
In-Reply-To: <200405141314.i4EDEgh29487@fannich.roe.ac.uk>
Message-ID: <Pine.LNX.4.44.0405141228000.15810-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7,
	BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37,
	QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Martin -

On Fri, 14 May 2004, Martin Hill wrote:
> The data model would be the wrong place to put non-standard things :-)

Not in the data model, in the dataset instance.  The dataset is an instance
of the data model, and must conform to the data model, but it can contain
nonstandard extensions to convey information specific to the actual dataset.
This would normally be put there by the data provider.

 
> Quality threshold values I would have thought would be set by the datacenters 
> - after all, these are the people who have already set effective threshold 
> values when working out binary or trinary quality values. Later we can model 
> quality more carefully.

We need to define something in the model for quality.  Then as you say,
it is up to the data provider to define this value when they map their data
into the standard data model.

 
> Which brings us to another point; if we can model the quality of an 
> individual bit of data, how do we model quality on large groups such as 
> datasets?  Presumably some datasets are better than others, and so the data 
> 'as a whole' has better value than another one - particularly as I understand 
> it even undergraduates should be able to post their data on the VO in order 
> to use VO tools, and to allow other people to use their data :-).

This is a hard problem, but would be a reasonable thing to do in the
level 1 (registry) or level 2 (uniform dataset characterization) metadata.
Better yet we should refine the level 2 metadata to provide uniform
information about resolution, sensitivity, etc., then we can do this 
quantitatively.

	- Doug



> On Friday 14 May 2004 1:45 pm, Ivo Busko wrote:
> > Doug Tody wrote:
> > <snip>
> >
> > > Ivo - regarding your point about data quality vectors:  As you know,
> > > the SSA data model has a data quality vector.  We don't really know what
> > > to put in it though.  I don't think we should put anything instrumental
> > > in nature in the general SSA data model (this can be done but it would
> > > go into nonstandard extension records).  Simple models for the quality
> > > vector would be binary (good or bad) or trinary (known good, known bad
> > > or flagged, or questionable).  Perhaps once we get more experience with
> > > real data from archives it will be possible to develop a more refined
> > > quality model.  (Note this should not be confused with the error vectors
> > > which we already have).
> > >
> > >         - Doug
> >
> > Thanks, Doug, that sounds good enough. I agree that nothing
> > instrument-specific
> > should be put in the data model. However, something must be done to
> > accomodate
> > cases that do not follow the norm.
> >
> > I have in mind cases where a binary or trinary model wouldn't be enough
> > to summarize the data quality information available in the original
> > file.
> > A good example is FUSE data; it uses a continuously variable 2-byte
> > integer
> > value to store a kind of "weight" (between 0 an 100), instead of the
> > more
> > commonly found bit-encoded mask. To cast that data into a, say, binary
> > good/bad
> > model, one needs an additional piece of information, in the form of a
> > threshold
> > value.
> >
> > Ideally, a VO transaction involving such data should allow for the
> > threshold
> > value to be either specified by the requestor, or alternatively be set
> > by the
> > data provider in a instrument-dependent way.
> >
> > In short, my point is: shouldn't the data model allow some room for
> > non-standard
> > extra bits of info such as data quality threshold values?
> >
> > Cheers,
> >
> > -Ivo
> 
> 

From owner-apps@eso.org  Fri May 14 20:46:30 2004
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EIkGRL015056
	for <apps-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 20:46:17 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4EIkGxD015055
	for apps-outgoing; Fri, 14 May 2004 20:46:16 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EIk8RL015037;
	Fri, 14 May 2004 20:46:08 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4EIk6Xe007918;
	Fri, 14 May 2004 20:46:06 +0200 (CEST)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i4EIk2N18264;
	Fri, 14 May 2004 12:46:02 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i4EIjwTU010602;
	Fri, 14 May 2004 12:46:00 -0600 (MDT)
Date: Fri, 14 May 2004 12:45:58 -0600 (MDT)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: Thomas.A.McGlynn@nasa.gov
cc: apps@ivoa.net, <dal@ivoa.net>
Subject: Re: Putting the pieces together...
In-Reply-To: <40A4CD8A.80208@lheapop.gsfc.nasa.gov>
Message-ID: <Pine.LNX.4.44.0405141236430.15810-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.2, required 7,
	BAYES_01 -5.40, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Tom -

> But the SSA doesn't say beans about using the spectra. What does it mean
> to say that we have an SSA data model? Is that different from the
> spectrum data model?  What does it mean to have any data model in terms
> of the software I'm going to write?  I don't think it means that all
> of the data files are in the same format.  Or does it?  Does it mean
> that there is some standard software package that can read these data?
> How do these quantity and measurement models fit in? Do these things mean the
> the data provider has provided a suite of tools that
> can access files or columns with tables?  Presumably I can <use> the
> data model in some way but I don't have a clue how.

> As a developer of a piece of software that's going to try to plot
> spectra that 'have' the spectral data model, I need to write code that
> gets information from the files.  How does the data model help me
> do that?  I mean this not in some abstract sense of organizing concepts
> but understanding the lines of code I might write.

When you use SSA you will get back a spectrum (or SED) which conforms to the
SSA data model.  It won't matter what format the data is in so long as your
application can parse it, since all formats encode the same data object.
The data model merely defines how the spectrum is put together and what
the elements are, so that you can write software to deal with it.  It is
no different from getting a spectrum from an archive or data analysis
system now, except that more effort has done into formally documenting
the science data model of the spectrum, and the representation in terms
of some external data format.

 
> I'm not suggesting that data models, UTYPEs, UCDs and all of this
> aren't useful, but that the discussion of them has focused so much
> on the underlying abstractions in the data, that how they
> connect with and are used in VO applications is completely opaque,
> at least to me.   Personally I suspect that if we had some more concrete
> sense of how these data elements and structures were going to
> be used we'd have a lot easier time defining what they should look like.

I agree, too much of the discussion has been at that level.  That is
why I thought your use case was right on the money.  We need to do some
end-to-end real world applications to get things back to reality.

	- Doug

From owner-apps@eso.org  Fri May 14 22:32:27 2004
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EKWARL024490
	for <apps-outgoing@mercury.hq.eso.org>; Fri, 14 May 2004 22:32:10 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4EKWAvA024489
	for apps-outgoing; Fri, 14 May 2004 22:32:10 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4EKW7RL024485;
	Fri, 14 May 2004 22:32:07 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4EKW4Xe012450;
	Fri, 14 May 2004 22:32:04 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i4EKW2Sb005964;
	Fri, 14 May 2004 14:32:02 -0600
Date: Fri, 14 May 2004 14:31:59 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Thomas.A.McGlynn@nasa.gov
cc: apps@ivoa.net, <dal@ivoa.net>
Subject: Re: Putting the pieces together...
In-Reply-To: <40A51CA5.8040901@lheapop.gsfc.nasa.gov>
Message-ID: <Pine.LNX.4.44.0405141340530.1254-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Tom -

It will probably be simpler to discuss this once we have the data model and
interface specifications to review (hopefully next week), but a little more
discussion should be helpful.

> > When you use SSA you will get back a spectrum (or SED) which conforms to the
> > SSA data model.  It won't matter what format the data is in so long as your
> > application can parse it, since all formats encode the same data object.
> 
> What does this mean...  "conforms to the data model?"  Does this
> mean that we're getting back a file that's in XML with a schema somewhere
> and items identified in the schema?  Data cannot be in FITS?

The science data model (SDM) for a spectrum, SED, or whatever defines
the required and optional data elements, their allowed values, and their
meanings and relationships.  The thinking now is that the SDM includes
a reference serialization in XML including a schema.

At the SDM level this is all rather abstract.  The data access interface
(SSA in this case) defines both the query interface for the particular type
of data in question, e.g., a spectrum, and the standard formats in which
data can be returned, i.e., an export data format (EDF) such as VOTable,
FITS, XML, etc.

Each EDF is a physical realization of the SDM in some specific format.
In the case of VOTable the tabular elements of the SDM are represented
in tables, and UTYPE values are given to refer the table fields back to
elements of the SDM.  In the case of FITS, the EDF defines the mapping of
the SDM into specific FITS representations, such as one or more binary
tables or one or more rows of a single binary table, with 8-character
FITS keyword names for all elements of the SDM (for FITS the keyword name
takes the place of UTYPE).

In theory, regardless of what file format is used, the same data object
is returned.  The chief difference is that some formats may be more
permissible in terms of nonstandard extensions than others (generic
containers like VOTable are more permissible in this regard than pure
XML representations of a specific data model).

 
> Or maybe it means that the data can be in FITS or XML, but the data can
> be deserialized using some standard applications that recognize
> the formats and allow the users some  API to the data?  There's
> a set of standard Java interfaces and classes  that are provided by the VO.
> Wil writes an equivalent set that C# users can try.

Data can be in any format for which a standard mapping has been defined
by the access interface.  Yes, one could write a standard wrapper
class to decode any standard format and return the object via an API.
Ultimately we will probably want to provide reference code for both the
server side (a data access framework for implementing services) and for
the client side (libraries in major languages for applications to use).
Or applications developers will just write their own client interface.


> Or maybe it means that there are converter tools that know how to
> transform the data into a standard representation for a given data model?
> The converter tools are invokable from a few standard Web sites.

Transforming the data *into* a standard representation occurs mainly on
the server side and is done by the data access service.  If the server
generates data in one format, e.g., XML, a standard module on the server
side could automatically generate the format requested by the client.
We could also make these transformer modules available as web services
but this should be avoided.  Or the service might generate any format
directly in order to have maximum control over formatting, e.g., to be
able to add nonstandard extensions.

 
> These are three very different ways I could see a data model being
> instantiated usefully within the VO.  There are probably others, CORBA
> and IDL could probably play a role.  I could understand what conforming
> to a data model means if it meant one or more of these!

CORBA could also be used but this is something one would normally use
only for local area computing, e.g., to use a DAL service within a cluster
(SOAP is better for wide area computing such as for VO).  For example, we
could implement a data access component to implement the client side of
a DAL service, using an API conformant to the SDM to provide concurrent
access to the data object to applications code running on a cluster.
The data access component would use a web service interface to talk to
the VO to fetch the data object, and a CORBA interface (or whatever)
to provide high performance shared access to the data within the cluster.

Again, the key thing here is that the data object conforms to the SDM.
The application sees only the SDM, and doesn't care about all the different
data access protocols and formats.


> Or does it mean, as you seem to imply below, that the data model is just
> a bit of documentation that is somehow associated with the file but
> every application needs to build their own custom parsers?  I surely hope
> that's not what it is.

A data model is an abstract definition, but this does not mean every
application needs to build their own custom parsers.  An existing example
is FITS WCS.  FITS WCS is defined in a document.  Various parties write
class code to implement WCS.  We extract a WCS from some dataset, retrieve
it from a database, or whatever, load it into some WCS class library, and
we can use the WCS.


> To me the real purpose of data models is that I can
> build high level interfaces over the data model and hide
> low level implementation details.  The VO provides me
> with some way of getting the standard information  regardless
> of the low level stuff.  But if everyone has to build their
> own low level interfaces that's not going to win us any friends!  Every time
> a new low level format comes along everyone needs to update their codes.
> That can't be right.

This is pretty much right.  Having an abstract definition of the data
model means that it is defined independently of the implementation,
so your applications code does not have to know about all the various
protocols and access interfaces.

 
> If the data model is only documentation then
> I think we've wasted a lot of time on this.  Just as resource
> metadata isn't very helpful without registries
> that give us common access to metadata from many resources, data model
> metadata isn't very helpful unless we have API's that give us common
> access to datasets which implement these models.
> 
> What are the software capabilities that the data models are associated with?

This is completely undefined.  Of course you can write any sort of
application to manipulate such data.


We seem to be having an abstract discussion about something which is
actually pretty straightforward.  Once we have initial implementations of
SSA services we should write an actual application or two, and demonstrate
things end-to-end.  This will make it all a lot more concrete.

	- Doug

From owner-dal@eso.org  Mon May 17 20:36:46 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4HIaQgw019607
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 17 May 2004 20:36:26 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4HIaQXK019606
	for dal-outgoing; Mon, 17 May 2004 20:36:26 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4HIaHgw019586;
	Mon, 17 May 2004 20:36:17 +0200 (MEST)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4HIaFTY004761;
	Mon, 17 May 2004 20:36:16 +0200 (CEST)
Received: from SARA (roy-nat.cacr.caltech.edu [131.215.144.149])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4HIaEk4012957
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 17 May 2004 11:36:14 -0700
Message-ID: <0a8e01c43c3d$fc8765e0$0c0ba8c0@cacr.caltech.edu>
From: "Roy Williams" <roy@caltech.edu>
To: <ucd@ivoa.net>
Cc: <dal@ivoa.net>
Subject: UCD agenda and UCD/DAL agenda
Date: Mon, 17 May 2004 11:37:19 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@caltech.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Please find below a suggested draft agenda for the UCD session at the
Interop meeting.

Note that the second half is joint with the DAL group.

If you would like to contribute to the session, or change the agenda below,
please drop me a line.

Roy

----------------------------------------------

UCD working group
Agenda for Interop meeting

1. Sebastien Derriere, UCD Services at CDS
2. Andrea Preite-Martinez, Realization of UCD1+
3. Roy Williams, UCDs for the Image Access Protocol
4. Doug Tody, UCDs for the Spectral Access Protocol

--------
California Institute of Technology
roy@caltech.edu
626 395 3670

From owner-dal@eso.org  Sat May 22 00:45:38 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4LMjJU3024776
	for <dal-outgoing@mercury.hq.eso.org>; Sat, 22 May 2004 00:45:19 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4LMjJvV024775
	for dal-outgoing; Sat, 22 May 2004 00:45:19 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4LMjFU3024768
	for <dal@ivoa.net>; Sat, 22 May 2004 00:45:16 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4LMjDTY015308
	for <dal@ivoa.net>; Sat, 22 May 2004 00:45:14 +0200 (CEST)
Received: from zia.aoc.nrao.edu (zia [146.88.1.4])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i4LMj8N09928
	for <dal@ivoa.net>; Fri, 21 May 2004 16:45:08 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by zia.aoc.nrao.edu (8.12.9/8.12.5) with ESMTP id i4LMj6TU018669;
	Fri, 21 May 2004 16:45:06 -0600 (MDT)
Date: Fri, 21 May 2004 16:45:06 -0600 (MDT)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net
Subject: Updated InterOp2004 agenda
Message-ID: <Pine.LNX.4.44.0405211641310.6501-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.4, required 7,
	BAYES_01 -5.40, USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

I put an updated agenda for the DAL sessions online at

    http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2004DAL

Authors should feel free to upload copies of their documents or
presentations.  Otherwise I will put copies on the page of everything
I have by the end of the day today.     Doug

From owner-dal@eso.org  Sat May 22 17:12:25 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4MFBwU3011962
	for <dal-outgoing@mercury.hq.eso.org>; Sat, 22 May 2004 17:11:58 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4MFBw9c011959
	for dal-outgoing; Sat, 22 May 2004 17:11:58 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4MFBsU3011952
	for <dal@ivoa.net>; Sat, 22 May 2004 17:11:55 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4MFBqXe009518
	for <dal@ivoa.net>; Sat, 22 May 2004 17:11:53 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i4MFBgSb019294;
	Sat, 22 May 2004 09:11:43 -0600
Date: Sat, 22 May 2004 09:11:41 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: dal@ivoa.net
Subject: Re: Updated InterOp2004 agenda
In-Reply-To: <Pine.LNX.4.44.0405211641310.6501-100000@oak>
Message-ID: <Pine.LNX.4.44.0405220859230.1254-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-RAVMilter-Version: 8.4.3(snapshot 20030212) (virgo)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Fri, 21 May 2004, Doug Tody wrote:
> I put an updated agenda for the DAL sessions online at
> 
>     http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2004DAL
> 
> Authors should feel free to upload copies of their documents or
> presentations.  Otherwise I will put copies on the page of everything
> I have by the end of the day today.     Doug

Background reading materials for the DAL session are now online at the
Wiki at the above URL.  Authors or presenters should feel free to edit
this page to update documents or add new ones.  In particular please
update your presentations when you have them available (at the very least
by the end of the meeting).

For SSA what is available is a fairly detailed SSA data model (this is the
basis for SSA and is where most of our work has gone) and a SSA interface
summary.  While the documents are still rough, SSA is now detailed enough
that we can argue details.  The scope is SEDs, spectra, and time series,
all of which share the same core spectrophotometric data model.

	- Doug

From owner-dal@eso.org  Tue May 25 05:12:00 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4P3BDow025979
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 25 May 2004 05:11:13 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4P3BDDA025978
	for dal-outgoing; Tue, 25 May 2004 05:11:13 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4P3B5ow025935;
	Tue, 25 May 2004 05:11:05 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4P3B4Xe017157;
	Tue, 25 May 2004 05:11:04 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i4P3B3pD045625
          ; Tue, 25 May 2004 05:11:04 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id FAA14093;
	Tue, 25 May 2004 05:06:02 +0200 (MET DST)
Date: Tue, 25 May 2004 05:06:02 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200405250306.FAA14093@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: Utypes and SIAP evolution
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear Dal and DM members
This mail is to be replied on DAL ONLY, to
avoid cross posting inflation.

      The two notes I edited in April:
"Data Model serialisation in VOTable (M.Louys, F.bonnarel)"
and
"Proposal for an evolution of the SIA protocol (T.Boch et al)"
are now available since Friday as "official" IVOA Notes
http://www.ivoa.net/Documents/Notes/DMVOTSer/DMVOTSer.html
and
http://www.ivoa.net/Documents/Notes/SIAPEvol/SIAPEvol.html
The example in the second of these notes has been upgraded since April with
a tentative ivoa:observation utype flagging.
This takes into accounts JMcDowell proposal : "Utypes for SIAP"
and the IVOA Observation data model working draft and diagrams,
which contain "draft" attributes.

In some cases we looked for alternative utypes from STC or Quantity
Data models. We do not see it as a drawback to have several utypes    
(actually a multipart single utype) for the same field in our VOTable.

In the context of this SIAP evolution proposal, where we describe 
Observations in a structured VOTable, what do we expect from the
utypes: 
     Provide an accurate IVOA/admitted definition for our fields.
And therefore allow any kind of software reading and interpreting this
VOTable to take appropriate decisions.

    In conclusion: the structure of our VOTable maps an "intermediate"
data model, ie between proprietary data model and IVOA data model (in our
example it is the IDHA one, but it could be any other of this type).
The utype gives the"official"  link(s) to the IVOA DM(s)


Regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dm@eso.org  Tue May 25 05:12:22 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4P3B9ow025964
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 25 May 2004 05:11:09 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4P3B9q3025952
	for dm-outgoing; Tue, 25 May 2004 05:11:09 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4P3B5ow025935;
	Tue, 25 May 2004 05:11:05 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4P3B4Xe017157;
	Tue, 25 May 2004 05:11:04 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i4P3B3pD045625
          ; Tue, 25 May 2004 05:11:04 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id FAA14093;
	Tue, 25 May 2004 05:06:02 +0200 (MET DST)
Date: Tue, 25 May 2004 05:06:02 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200405250306.FAA14093@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: Utypes and SIAP evolution
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear Dal and DM members
This mail is to be replied on DAL ONLY, to
avoid cross posting inflation.

      The two notes I edited in April:
"Data Model serialisation in VOTable (M.Louys, F.bonnarel)"
and
"Proposal for an evolution of the SIA protocol (T.Boch et al)"
are now available since Friday as "official" IVOA Notes
http://www.ivoa.net/Documents/Notes/DMVOTSer/DMVOTSer.html
and
http://www.ivoa.net/Documents/Notes/SIAPEvol/SIAPEvol.html
The example in the second of these notes has been upgraded since April with
a tentative ivoa:observation utype flagging.
This takes into accounts JMcDowell proposal : "Utypes for SIAP"
and the IVOA Observation data model working draft and diagrams,
which contain "draft" attributes.

In some cases we looked for alternative utypes from STC or Quantity
Data models. We do not see it as a drawback to have several utypes    
(actually a multipart single utype) for the same field in our VOTable.

In the context of this SIAP evolution proposal, where we describe 
Observations in a structured VOTable, what do we expect from the
utypes: 
     Provide an accurate IVOA/admitted definition for our fields.
And therefore allow any kind of software reading and interpreting this
VOTable to take appropriate decisions.

    In conclusion: the structure of our VOTable maps an "intermediate"
data model, ie between proprietary data model and IVOA data model (in our
example it is the IDHA one, but it could be any other of this type).
The utype gives the"official"  link(s) to the IVOA DM(s)


Regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Tue May 25 17:45:07 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4PFickM016873
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 25 May 2004 17:44:38 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4PFicEl016872
	for dal-outgoing; Tue, 25 May 2004 17:44:38 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4PFiYkM016865
	for <dal@ivoa.net>; Tue, 25 May 2004 17:44:35 +0200 (MEST)
Received: from mail.cacr.caltech.edu (mail.cacr.caltech.edu [131.215.145.9])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4PFiWXe009807
	for <dal@ivoa.net>; Tue, 25 May 2004 17:44:33 +0200 (CEST)
Received: from Ropy (roam250-33.fas.harvard.edu [140.247.250.33])
	(authenticated bits=0)
	by mail.cacr.caltech.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4PFiJlk004639
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO)
	for <dal@ivoa.net>; Tue, 25 May 2004 08:44:20 -0700
Message-ID: <0bc001c4426f$258b3660$6601a8c0@Ropy>
From: "Roy Williams" <roy@cacr.caltech.edu>
To: <dal@ivoa.net>
Subject: SIAP with Logical Names
Date: Tue, 25 May 2004 08:44:19 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Roy Williams" <roy@cacr.caltech.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

As discussed in the DAL session this morning, please find below the proposed
extension of SIA to include "Logical Names".
-- Roy

----------------------------------------

Extending the SIAP with Logical Names

In the SIAP protocol, there are two parts: a metadata service that returns a
VOTable of images and their metadata, and each row of that table contains a
URL to a data service that will fetch an actual image in FITS or JPEG or
some other format.

The SIAP protocol defines the nature of the columns of the table that is
returned by the metadata service. What we considering in the following is to
specify a new, optional column, and the associated semantics.

(1) The Proposal
The proposal is to allow a new column called "Logical Name" (LN) which is
string valued.

(1.1) The string should be built from the same character set that is used in
identifer components (is this right Ray?)
         alpha | digits | "-" | "_" | "." | "~" | "$" | "&" | "=" | "+"

Specifically, this choice of characters will enable the LN to be used as
part of a Posix file name if desired by the consumer. This is useful for
bulk use of SIAP services where lots of files are stored; and it may not be
possible to deconstruct the URL to produce a suitable file name.

(1.2) If two rows of the table have the same LN, then we can assume they are
in some sense "the same" image. Comparison is case-sensitive. Interpretation
of this is not strictly defined, but some guidelines follow in the next
section.

(2) Guidelines
SIAP providers and consumers may ignore these guidelines and still be legal.

Recalling the metadata that MUST be present in each row, let us abbrieviate:
-- "Scale" is the scale pair from VOX:Image_Scale
-- "Naxes" is the scale pair from "VOX:Image_Naxes"
-- "Format" is the format from VOX:Image_Format
-- "Bandpass" is the bundle of bandpass metadata
-- "URL" is from the VOX:Image_AccessReference

The guidelines assume an SIAP table that has two rows that have a common LN.
We compare the rest of the metadata in the rows to reach "reasonable"
conclusions as specified below.

(2.1) If all the metadata in the two rows is the same except for the URLs, a
consumer may assume that exactly the same data (same bytestream) can be
fetched from the URLs.
-- There may be "normal" client-side processing to effect this, for example
those URLs ending in .gz would imply client-side decompression is needed
before the streams would be the same.
-- The URLs may have different hostnames -- thus providing support for
replica services.
-- The URLs may have different protocols, such as http:// and srb://, thus
providing support for alternate delivery methods.

(2.2) If all the metadata is the same except for the URLs and the Formats,
then a consumer may assume that the same data is present but in different
image formats. So there could be, for example, a FITS and a JPEG version of
the same image. The JPEG version may have a lower information content, but
is assumed to be exactly co-registered with the FITS version.

(2.3) If all the metadata is the same except for the URLs and the Scales and
Naxes, then a consumer may assume that the same information is present but
at a different scale. However, if the relevant ratios of the scales and the
Naxes are not right, then one image might be a cutout of another, or there
might be a mistake.

(2.4) Guidelines (2.2) and (2.3) can be combined so that we have a way to
find, for example, a quicklook Jpeg version of a Fits image.

(2.5) If all the metadata is the same except for the URLs and the Bandpass
packages, then a consumer may assume that these images are exactly
coregistered (stackable) but in different bandpass. A set of three
monochrome images could, for example, be identified and combined into a
color image.

--------
California Institute of Technology
roy@caltech.edu
626 395 3670

From owner-dal@eso.org  Tue May 25 18:36:40 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4PGaEkM023506
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 25 May 2004 18:36:14 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i4PGaEvb023505
	for dal-outgoing; Tue, 25 May 2004 18:36:14 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i4PGa9kM023485
	for <dal@ivoa.net>; Tue, 25 May 2004 18:36:09 +0200 (MEST)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i4PGa7Xe011899
	for <dal@ivoa.net>; Tue, 25 May 2004 18:36:07 +0200 (CEST)
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head.cfa.harvard.edu (d/w) with ESMTP id i4PGa4mv017127;
	Tue, 25 May 2004 12:36:04 -0400 (EDT)
From: Arnold Rots <arots@head.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id i4PGa4df004139;
	Tue, 25 May 2004 12:36:04 -0400 (EDT)
Message-Id: <200405251636.i4PGa4df004139@xebec.cfa.harvard.edu>
Subject: Re: SIAP with Logical Names
In-Reply-To: <0bc001c4426f$258b3660$6601a8c0@Ropy>
To: Roy Williams <roy@cacr.caltech.edu>
Date: Tue, 25 May 2004 12:36:04 -0400 (EDT)
CC: dal@ivoa.net
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Arnold Rots <arots@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

A mechanism like this is clearly needed.  e have run into this and
solved it, for the time being, by ncluding a column "ObsID".

  - Arnold

Roy Williams wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> As discussed in the DAL session this morning, please find below the proposed
> extension of SIA to include "Logical Names".
> -- Roy
> 
> ----------------------------------------
> 
> Extending the SIAP with Logical Names
> 
> In the SIAP protocol, there are two parts: a metadata service that returns a
> VOTable of images and their metadata, and each row of that table contains a
> URL to a data service that will fetch an actual image in FITS or JPEG or
> some other format.
> 
> The SIAP protocol defines the nature of the columns of the table that is
> returned by the metadata service. What we considering in the following is to
> specify a new, optional column, and the associated semantics.
> 
> (1) The Proposal
> The proposal is to allow a new column called "Logical Name" (LN) which is
> string valued.
> 
> (1.1) The string should be built from the same character set that is used in
> identifer components (is this right Ray?)
>          alpha | digits | "-" | "_" | "." | "~" | "$" | "&" | "=" | "+"
> 
> Specifically, this choice of characters will enable the LN to be used as
> part of a Posix file name if desired by the consumer. This is useful for
> bulk use of SIAP services where lots of files are stored; and it may not be
> possible to deconstruct the URL to produce a suitable file name.
> 
> (1.2) If two rows of the table have the same LN, then we can assume they are
> in some sense "the same" image. Comparison is case-sensitive. Interpretation
> of this is not strictly defined, but some guidelines follow in the next
> section.
> 
> (2) Guidelines
> SIAP providers and consumers may ignore these guidelines and still be legal.
> 
> Recalling the metadata that MUST be present in each row, let us abbrieviate:
> -- "Scale" is the scale pair from VOX:Image_Scale
> -- "Naxes" is the scale pair from "VOX:Image_Naxes"
> -- "Format" is the format from VOX:Image_Format
> -- "Bandpass" is the bundle of bandpass metadata
> -- "URL" is from the VOX:Image_AccessReference
> 
> The guidelines assume an SIAP table that has two rows that have a common LN.
> We compare the rest of the metadata in the rows to reach "reasonable"
> conclusions as specified below.
> 
> (2.1) If all the metadata in the two rows is the same except for the URLs, a
> consumer may assume that exactly the same data (same bytestream) can be
> fetched from the URLs.
> -- There may be "normal" client-side processing to effect this, for example
> those URLs ending in .gz would imply client-side decompression is needed
> before the streams would be the same.
> -- The URLs may have different hostnames -- thus providing support for
> replica services.
> -- The URLs may have different protocols, such as http:// and srb://, thus
> providing support for alternate delivery methods.
> 
> (2.2) If all the metadata is the same except for the URLs and the Formats,
> then a consumer may assume that the same data is present but in different
> image formats. So there could be, for example, a FITS and a JPEG version of
> the same image. The JPEG version may have a lower information content, but
> is assumed to be exactly co-registered with the FITS version.
> 
> (2.3) If all the metadata is the same except for the URLs and the Scales and
> Naxes, then a consumer may assume that the same information is present but
> at a different scale. However, if the relevant ratios of the scales and the
> Naxes are not right, then one image might be a cutout of another, or there
> might be a mistake.
> 
> (2.4) Guidelines (2.2) and (2.3) can be combined so that we have a way to
> find, for example, a quicklook Jpeg version of a Fits image.
> 
> (2.5) If all the metadata is the same except for the URLs and the Bandpass
> packages, then a consumer may assume that these images are exactly
> coregistered (stackable) but in different bandpass. A set of three
> monochrome images could, for example, be identified and combined into a
> color image.
> 
> --------
> California Institute of Technology
> roy@caltech.edu
> 626 395 3670
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From owner-dal@eso.org  Tue Jun  1 19:23:28 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51HMuV4013266
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Jun 2004 19:22:57 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i51HMu2A013265
	for dal-outgoing; Tue, 1 Jun 2004 19:22:56 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51HMlV4013243;
	Tue, 1 Jun 2004 19:22:47 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i51HMlp06547;
	Tue, 1 Jun 2004 19:22:47 +0200 (MEST)
Message-ID: <40BCBB82.9070405@eso.org>
Date: Tue, 01 Jun 2004 19:23:14 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Doug Tody <dtody@nrao.edu>
CC: IVOA Data Access Layer <dal@ivoa.net>
Subject: application/votable+xml
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi Doug,

During the SSA interface discussion in Boston last week the question arose how 
a (pseudo) mime-type for VOTable should look like. After some investigation my 
conclusion is:

application/votable+xml

For an explanation why to use "+" as a delimiter, why to append "+xml" to the 
subtype and what would happen if one decided to choose a different solution see 
the discussion and examples in "XML Media Types" 
(http://www.ietf.org/rfc/rfc3023.txt).

Similar recommended types are for instance:
application/xslt+xml, application/rdf+xml, application/mathml+xml

The only irritating bit is that I'm unable to find a mime type list that is 
newer than 3 years. Moreover, IETF does not have a top level link to MIME on 
their home page which is a surprise since supposedly IETF is in charge of 
it(?). This makes we wonder whether either MIME is obsolete in some way or 
maybe I was looking in the wrong place?

Cheers,
Markus



From owner-dal@eso.org  Tue Jun  1 20:13:33 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51IDEV4020590
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Jun 2004 20:13:15 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i51IDEIL020589
	for dal-outgoing; Tue, 1 Jun 2004 20:13:14 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51IDBV4020573;
	Tue, 1 Jun 2004 20:13:11 +0200 (MEST)
Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i51IDATY002747;
	Tue, 1 Jun 2004 20:13:10 +0200 (CEST)
Received: from [144.173.229.16] (helo=dastardly.astro.ex.ac.uk)
	by mercury.ex.ac.uk with esmtp (Exim 4.30)
	id 1BVDl7-01SvnI-Ol; Tue, 01 Jun 2004 19:13:09 +0100
Received: from localhost by dastardly.astro.ex.ac.uk; Tue, 1 Jun 2004 19:13:09 +0100
Date: Tue, 1 Jun 2004 19:13:09 +0100 (BST)
From: Alasdair Allan <aa@astro.ex.ac.uk>
To: Markus Dolensky <Markus.Dolensky@eso.org>
cc: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: application/votable+xml
In-Reply-To: <40BCBB82.9070405@eso.org>
Message-ID: <Pine.LNX.4.44.0406011909530.2587-100000@dastardly.astro.ex.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alasdair Allan <aa@astro.ex.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


> The only irritating bit is that I'm unable to find a mime type list that
> is newer than 3 years. Moreover, IETF does not have a top level link to
> MIME on their home page which is a surprise since supposedly IETF is in
> charge of it(?). This makes we wonder whether either MIME is obsolete in
> some way or maybe I was looking in the wrong place?

The official list of MIME types is maintained by IANA, and is governed
by RFC2045 and RFC2046. The last officially recognised type list was
published on 16-Oct-2001 as far as I can tell.

Like the astronomy communities struggle with FITS HDU card standards,
trying to get a new MIME type "approved" is practically impossible these
days, or at least so I'm lead to believe.

Al.
-- 
Dr. A. Allan, School of Physics, University of Exeter

From owner-dal@eso.org  Tue Jun  1 21:58:30 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51Jw3V4010764
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Jun 2004 21:58:04 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i51Jw3IH010763
	for dal-outgoing; Tue, 1 Jun 2004 21:58:03 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51JvxV4010740;
	Tue, 1 Jun 2004 21:57:59 +0200 (MEST)
Received: from othello.physics.gla.ac.uk (othello.physics.gla.ac.uk [130.209.204.200])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i51JvvTY009581;
	Tue, 1 Jun 2004 21:57:57 +0200 (CEST)
Received: from kronecker.demon.co.uk ([80.177.13.240] helo=[10.0.0.1])
	by othello.physics.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128)
	(Exim 4.14)
	id 1BVFOW-0000lw-KH; Tue, 01 Jun 2004 20:57:56 +0100
In-Reply-To: <40BCBB82.9070405@eso.org>
References: <40BCBB82.9070405@eso.org>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F4E4C1E5-B405-11D8-B950-000D93C1FC1C@astro.gla.ac.uk>
Content-Transfer-Encoding: 7bit
Cc: IVOA Data Access Layer <dal@ivoa.net>
From: Norman Gray <norman@astro.gla.ac.uk>
Subject: Re: application/votable+xml
Date: Tue, 1 Jun 2004 20:57:48 +0100
To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 1.5 (+)
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BVFOW-0000lw-KH*wo/mYFNyjoQ*
X-Othello-SMTP: True
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Norman Gray <norman@astro.gla.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Markus,

On 2004 Jun 1 , at 18.23, Markus Dolensky wrote:

> application/votable+xml

I for one agree, with the qualification below.

> For an explanation why to use "+" as a delimiter, why to append "+xml"  
> to the subtype and what would happen if one decided to choose a  
> different solution see the discussion and examples in "XML Media  
> Types" (http://www.ietf.org/rfc/rfc3023.txt).

The general RFC for registering MIME types is RFC 2048  
<http://www.imc.org/rfc2048>, which is being updated at present (see  
<http://www.imc.org/draft-freed-mime-p4>).  The process is long-winded  
(as the FITS community is finding out), but doesn't look massively  
hard.

I think we should embark on the standardisation process, on the  
assumption that the VO is more than a brief fashion.  Specifically, we  
don't have to wait until VOTable is `finished', as there's no version  
information in the MIME type.

Until that point, however, we should use the `Experimental' MIME  
prefix, and should use

x-application/votable+xml

Only registered types should use the version without leading `x-'

> The only irritating bit is that I'm unable to find a mime type list  
> that is newer than 3 years. Moreover, IETF does not have a top level  
> link to MIME on their home page which is a surprise since supposedly  
> IETF is in charge of it(?). This makes we wonder whether either MIME  
> is obsolete in some way or maybe I was looking in the wrong place?

The canonical list of MIME types is  
<http://www.iana.org/assignments/media-types/>.  It's not mentioned in  
RFC2048, but is in the draft update -- I agree the IANA and the IETF  
should have a more prominent link to it.

I believe Microsoft will tell you that MIME is obsolete, and that their  
DIME is the very thing to replace it with.  This view is... not widely  
held.

I hope this helps,

Norman


--  
------------------------------------------------------------------------ 
---
Norman Gray                         
http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK      
norman@astro.gla.ac.uk

From owner-dal@eso.org  Tue Jun  1 23:17:08 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51LGgV4025680
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Jun 2004 23:16:43 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i51LGgsI025679
	for dal-outgoing; Tue, 1 Jun 2004 23:16:42 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51LGWV4025642;
	Tue, 1 Jun 2004 23:16:32 +0200 (MEST)
Received: from atum.hq.eso.org (atum.hq.eso.org [134.171.42.41])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i51LGWp12431;
	Tue, 1 Jun 2004 23:16:32 +0200 (MEST)
Received: (from apache@localhost)
	by atum.hq.eso.org (8.11.6/8.8.8) id i51LGWj28130;
	Tue, 1 Jun 2004 23:16:32 +0200
Received: from pD9E95FF1.dip.t-dialin.net (pD9E95FF1.dip.t-dialin.net [217.233.95.241]) 
	by webmail.eso.org (IMP) with HTTP 
	for <amicol@localhost>; Tue,  1 Jun 2004 23:16:32 +0200
Message-ID: <1086124592.40bcf23006849@webmail.eso.org>
Date: Tue,  1 Jun 2004 23:16:32 +0200
From: Alberto Micol <Alberto.Micol@eso.org>
To: Norman Gray <norman@astro.gla.ac.uk>
Cc: Markus Dolensky <Markus.Dolensky@eso.org>,
   IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: application/votable+xml
References: <40BCBB82.9070405@eso.org> <F4E4C1E5-B405-11D8-B950-000D93C1FC1C@astro.gla.ac.uk>
In-Reply-To: <F4E4C1E5-B405-11D8-B950-000D93C1FC1C@astro.gla.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 217.233.95.241
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Alberto Micol <Alberto.Micol@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Quoting Norman Gray <norman@astro.gla.ac.uk>:

> 
> Markus,
> 
> On 2004 Jun 1 , at 18.23, Markus Dolensky wrote:
> 
> > application/votable+xml
> ...
> 
> Until that point, however, we should use the `Experimental' MIME  
> prefix, and should use
> 
> x-application/votable+xml
> 
> Only registered types should use the version without leading `x-'
> 

Indeed, I do recall the x- for non-registered mime types, but,
if I'm not wrong, it should be on the other side like in:

application/x-votable+xml


Alberto

From owner-dal@eso.org  Tue Jun  1 23:51:16 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51Lounc000156
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Jun 2004 23:50:56 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i51LoupF000155
	for dal-outgoing; Tue, 1 Jun 2004 23:50:56 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i51Lopnc000136;
	Tue, 1 Jun 2004 23:50:51 +0200 (MEST)
Received: from othello.physics.gla.ac.uk (othello.physics.gla.ac.uk [130.209.204.200])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i51LonTY017635;
	Tue, 1 Jun 2004 23:50:49 +0200 (CEST)
Received: from kronecker.demon.co.uk ([80.177.13.240] helo=[10.0.0.1])
	by othello.physics.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128)
	(Exim 4.14)
	id 1BVH9k-0001fy-Ow; Tue, 01 Jun 2004 22:50:48 +0100
In-Reply-To: <1086124592.40bcf23006849@webmail.eso.org>
References: <40BCBB82.9070405@eso.org> <F4E4C1E5-B405-11D8-B950-000D93C1FC1C@astro.gla.ac.uk> <1086124592.40bcf23006849@webmail.eso.org>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B9029E59-B415-11D8-B950-000D93C1FC1C@astro.gla.ac.uk>
Content-Transfer-Encoding: 7bit
Cc: IVOA Data Access Layer <dal@ivoa.net>,
   Markus Dolensky <Markus.Dolensky@eso.org>
From: Norman Gray <norman@astro.gla.ac.uk>
Subject: Re: application/votable+xml
Date: Tue, 1 Jun 2004 22:50:39 +0100
To: Alberto Micol <Alberto.Micol@eso.org>
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 1.5 (+)
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1BVH9k-0001fy-Ow*UAUjTdCOomY*
X-Othello-SMTP: True
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Norman Gray <norman@astro.gla.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Alberto,

On 2004 Jun 1 , at 22.16, Alberto Micol wrote:

>> x-application/votable+xml
>>
>> Only registered types should use the version without leading `x-'
>>
>
> Indeed, I do recall the x- for non-registered mime types, but,
> if I'm not wrong, it should be on the other side like in:
>
> application/x-votable+xml

Perfectly correct -- sorry about that.  I now see the grammar is in  
section 5.1 of RFC2045 <http://www.ietf.org/rfc/rfc2045.txt>, along  
with the statement:

 > There are, therefore, two acceptable mechanisms for defining new  
media subtypes:
 >
 >    (1)   Private values (starting with "X-") may be defined
 >         bilaterally between two cooperating agents without
 >         outside registration or standardization. Such values
 >          cannot be registered or standardized.
 >
 >    (2)   New standard values should be registered with IANA as
 >          described in RFC 2048.

Norman


--  
------------------------------------------------------------------------ 
---
Norman Gray                         
http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK      
norman@astro.gla.ac.uk

From owner-dal@eso.org  Wed Jun  2 14:04:44 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i52C43JQ011448
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 2 Jun 2004 14:04:03 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i52C430Y011447
	for dal-outgoing; Wed, 2 Jun 2004 14:04:03 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i52C3xJQ011426
	for <dal@ivoa.net>; Wed, 2 Jun 2004 14:03:59 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i52C3xp27823
	for <dal@ivoa.net>; Wed, 2 Jun 2004 14:03:59 +0200 (MEST)
Message-ID: <40BDC24B.2000302@eso.org>
Date: Wed, 02 Jun 2004 14:04:27 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: IVOA Data Access Layer <dal@ivoa.net>
Subject: application/x-votable+xml
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Ok. We converged on MIME type ...

"application/x-votable+xml"

... as reflected by the new subject line. Thanks to Alasdair, Alberto and 
Norman for the clarifications.

***

About the question of actually registering such a mime type:

"application" and "+xml" are already recognized. It's eventually an issue for 
the VOTable group, but I would think that even if "votable+xml" is a recognized 
subtype, non astronomer's tools could hardly do anything better than activating 
some default xml mode similar to what happens when just "+xml" is encountered.

My motivation was to recommend a proper value for the FORMAT parameter of the 
SSA interface spec. which is due in the coming weeks. To me a registered mime 
type makes sense if VOTable is used for outreach/education products and we 
intend to support special plug-ins for a broad public - but I don't think 
VOTable is likely to replace SVG or the like.

Regards,
Markus




From owner-dal@eso.org  Mon Jun  7 18:30:42 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57GUKDZ024897
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 7 Jun 2004 18:30:21 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57GUK3I024894
	for dal-outgoing; Mon, 7 Jun 2004 18:30:20 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57GUEDZ024876
	for <dal@ivoa.net>; Mon, 7 Jun 2004 18:30:15 +0200 (MEST)
Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57GUDTY002324
	for <dal@ivoa.net>; Mon, 7 Jun 2004 18:30:13 +0200 (CEST)
Received: from 0-1pool5-78.nas1.thornton1.co.us.da.qwest.net ([67.4.5.78] helo=[10.0.1.4])
	by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1BXN0h-0001Ha-00; Mon, 07 Jun 2004 09:30:08 -0700
Date: Mon, 7 Jun 2004 10:29:53 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@colorado.tuc.noao.edu
To: Tamas Budavari <budavari@pha.jhu.edu>
cc: dal@ivoa.net, Pierre Didelon <pdidelon@cea.fr>,
   Laszlo Dobos <dobos@pha.jhu.edu>
Subject: Re: Spectrum Data Model Implementation
In-Reply-To: <Pine.LNX.4.44.0406071141220.13896-100000@skysrv.pha.jhu.edu>
Message-ID: <Pine.LNX.4.53.0406071020440.2738@colorado.tuc.noao.edu>
References: <Pine.LNX.4.44.0406071141220.13896-100000@skysrv.pha.jhu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Tamas -

On Mon, 7 Jun 2004, Tamas Budavari wrote:
> Those 3 columns are defined in the <Wavelength> tag, which in fact seems
> to be missing from the "simple" example. Thanks for pointing it out! This
> implementation was BTW following the IVOA twiki document
> 
> 	http://www.ivoa.net/internal/IVOA/IVOADMSpectraWP/spec.pdf
> 
> I think it's called something different in version 0.5 but still separate
> GROUP in VOTable terms.

The most recent version of the SSA data model I am aware of (V0.5) is the one
on the DAL wiki page from the Boston meeting, at

    http://www.ivoa.net/internal/IVOA/InterOpMay2004DAL/spec2.pdf
 
> Unfortunatelly, empty columns in the current data model (or class
> structure) can't be just omitted easily. If they were objects and not
> numbers, then we could make them nullable (or nilable). We may be able 
> to play some tricks here if really needed but in this prototype we kept
> everything even though didn't fill in all the fields.

So far as the *data model* is concerned the fields can generally be
omitted, or vector fields can be represented as scalars.  This is actually
a pretty important aspect of the SSA data model since dataset instances
will generally be much simpler then the full data model permits, with only
2-3 vector columns and many of the scalar parameters omitted or defaulted.
The interesting issue here is whether this flexibility in representation
can be implemented reasonably with XML Schema and WS.  Can we omit or
default defined elements, or extend the model with non-standard elements?

	- Doug

> 
> On Mon, 7 Jun 2004, Pierre Didelon wrote:
> 
> > 
> > 
> > Tamas Budavari wrote:
> > > I believe this is relevant for many people on the dm, dal, grid, apps and
> > > votable IVOA mailing lists, so I figured I'd send it to interop...
> > > 
> > > Following the proposal for the spectrum data model, we have completed a 
> > > first implementation of an XML Web Service that returns spectra in the 
> > > new VO (proposal) format. Please go to
> > > 
> > > 	http://www.voservices.net/SpectrumSchemaWs/
> > > 
> > > The links on the bottom of the page show you how our class gets serialized
> > > into different xml formats that might be simple or more complex depending
> > > on the content.  A VOTable version of them is also implemented for
> > > reference. 
> > Hi,
> > 
> > Concerning the simple spectra VOTAble serialisation,
> > you have only 5 FIELD definitions with 8 TD cells in each row.
> > comparing with XML, it seems that definitions of Wavelength, BinLow & BinHigh
> > are missing.
> > 
> > Fields without meaning full value (like Error, ErrorLow,ErrorHigh & Quality)
> > can't be omitted? Or given as PARAM in the header to specifiy default
> > or unknown values,
> > 
> > SY
> > 
> > 
> 
> 

From owner-dal@eso.org  Mon Jun  7 19:58:24 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57Hw3DZ002577
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 7 Jun 2004 19:58:03 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57Hw3qM002576
	for dal-outgoing; Mon, 7 Jun 2004 19:58:03 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57HvxDZ002569
	for <dal@ivoa.net>; Mon, 7 Jun 2004 19:57:59 +0200 (MEST)
Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57HvvTY004926
	for <dal@ivoa.net>; Mon, 7 Jun 2004 19:57:58 +0200 (CEST)
Received: from 0-1pool5-78.nas1.thornton1.co.us.da.qwest.net ([67.4.5.78] helo=[10.0.1.4])
	by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1BXONe-0002hg-00; Mon, 07 Jun 2004 10:57:55 -0700
Date: Mon, 7 Jun 2004 11:57:41 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@colorado.tuc.noao.edu
To: dal@ivoa.net
Subject: Re: Spectrum Data Model Implementation
In-Reply-To: <Pine.LNX.4.53.0406071020440.2738@colorado.tuc.noao.edu>
Message-ID: <Pine.LNX.4.53.0406071147500.2738@colorado.tuc.noao.edu>
References: <Pine.LNX.4.44.0406071141220.13896-100000@skysrv.pha.jhu.edu>
 <Pine.LNX.4.53.0406071020440.2738@colorado.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> On Mon, 7 Jun 2004, Tamas Budavari wrote:
> > Those 3 columns are defined in the <Wavelength> tag, which in fact seems
> > to be missing from the "simple" example. Thanks for pointing it out! This
> > implementation was BTW following the IVOA twiki document
> > 
> > 	http://www.ivoa.net/internal/IVOA/IVOADMSpectraWP/spec.pdf
> > 
> > I think it's called something different in version 0.5 but still separate
> > GROUP in VOTable terms.
> 
> The most recent version of the SSA data model I am aware of (V0.5) is the one
> on the DAL wiki page from the Boston meeting, at
> 
>     http://www.ivoa.net/internal/IVOA/InterOpMay2004DAL/spec2.pdf

The IVOADMSpectraWP page above also contains a copy of the V.05 data model
and is best place to go currently for updated versions.  For XML/VOTable
formatting experiments it probably doesn't matter much which version
we use.   Doug

From owner-dal@eso.org  Mon Jun  7 20:09:05 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57I8eDZ003393
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 7 Jun 2004 20:08:40 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57I8eiW003392
	for dal-outgoing; Mon, 7 Jun 2004 20:08:40 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57I8aDZ003387
	for <dal@ivoa.net>; Mon, 7 Jun 2004 20:08:37 +0200 (MEST)
Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57I8XXe019566
	for <dal@ivoa.net>; Mon, 7 Jun 2004 20:08:33 +0200 (CEST)
Received: from localhost (budavari@localhost)
	by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i57I8WO16771;
	Mon, 7 Jun 2004 14:08:32 -0400
X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs
Date: Mon, 7 Jun 2004 14:08:32 -0400 (EDT)
From: Tamas Budavari <budavari@pha.jhu.edu>
To: Doug Tody <dtody@nrao.edu>
cc: dal@ivoa.net, Pierre Didelon <pdidelon@cea.fr>,
   Laszlo Dobos <dobos@pha.jhu.edu>
Subject: Re: Spectrum Data Model Implementation
In-Reply-To: <Pine.LNX.4.53.0406071020440.2738@colorado.tuc.noao.edu>
Message-ID: <Pine.LNX.4.44.0406071400180.16352-100000@skysrv.pha.jhu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Tamas Budavari <budavari@pha.jhu.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Hi Doug,

> The most recent version of the SSA data model I am aware of (V0.5) is
> the one on the DAL wiki page from the Boston meeting, at
> 
>     http://www.ivoa.net/internal/IVOA/InterOpMay2004DAL/spec2.pdf

Super! We'll try to get the new version running in web services and post
the new xml schema as soon as possible. We'll be including the requested
fixes and will try to follow the latest draft best as we can while 
following the xsd standards.

Two quick questions:
 - Shouldn't TABDATA be TABLEDATA?
 - I don't see right now how I put in more SEDs for an object. 
   Where is the list? 

Cheers, T.

From owner-dal@eso.org  Mon Jun  7 20:51:03 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57IohDZ009778
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 7 Jun 2004 20:50:43 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57IohHx009777
	for dal-outgoing; Mon, 7 Jun 2004 20:50:43 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57IodDZ009772
	for <dal@ivoa.net>; Mon, 7 Jun 2004 20:50:40 +0200 (MEST)
Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57IocTY006072
	for <dal@ivoa.net>; Mon, 7 Jun 2004 20:50:38 +0200 (CEST)
Received: from 0-1pool5-78.nas1.thornton1.co.us.da.qwest.net ([67.4.5.78] helo=[10.0.1.4])
	by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1BXPCY-0006Ba-00; Mon, 07 Jun 2004 11:50:31 -0700
Date: Mon, 7 Jun 2004 12:50:16 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@colorado.tuc.noao.edu
To: Tamas Budavari <budavari@pha.jhu.edu>
cc: dal@ivoa.net, Pierre Didelon <pdidelon@cea.fr>,
   Laszlo Dobos <dobos@pha.jhu.edu>
Subject: Re: Spectrum Data Model Implementation
In-Reply-To: <Pine.LNX.4.44.0406071400180.16352-100000@skysrv.pha.jhu.edu>
Message-ID: <Pine.LNX.4.53.0406071239540.2738@colorado.tuc.noao.edu>
References: <Pine.LNX.4.44.0406071400180.16352-100000@skysrv.pha.jhu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Tamas -

(I am traveling BTW, and may be online only periodically through Weds)

On Mon, 7 Jun 2004, Tamas Budavari wrote:
> > The most recent version of the SSA data model I am aware of (V0.5) is
> > the one on the DAL wiki page from the Boston meeting, at
> > 
> >     http://www.ivoa.net/internal/IVOA/InterOpMay2004DAL/spec2.pdf
> 
> Super! We'll try to get the new version running in web services and post
> the new xml schema as soon as possible. We'll be including the requested
> fixes and will try to follow the latest draft best as we can while 
> following the xsd standards.

Note that V0.5 is the pre-Interop version, and does not yet reflect the
discussions we had at the Interop meetings.  It is the most recent version
currently available though.
 
> Two quick questions:
>  - Shouldn't TABDATA be TABLEDATA?

Right.  The VOTable serialization in the document is just a sketch and
is dated - I don't think it fully reflects the current data model and the
version shown in the document also has problems with XML formatting.

>  - I don't see right now how I put in more SEDs for an object. 
>    Where is the list? 

For a SED there is a SED descriptor object plus 1 or more Spectrum or
timeSeries objects (the SED segments).  Note there is a distinction between
SED, Spectrum, and TimeSeries services - they are based on the same data
model but are distinct services.  Hence if you are implementing a Spectrum
service, you do not have to know about SEDs, and the service can merely
return a Spectrum object.

	- Doug

From owner-dal@eso.org  Mon Jun  7 21:10:49 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57JAUDZ011908
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 7 Jun 2004 21:10:30 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57JAUHh011907
	for dal-outgoing; Mon, 7 Jun 2004 21:10:30 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57JAQDZ011879
	for <dal@ivoa.net>; Mon, 7 Jun 2004 21:10:27 +0200 (MEST)
Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57JAPTY006583
	for <dal@ivoa.net>; Mon, 7 Jun 2004 21:10:25 +0200 (CEST)
Received: from localhost (budavari@localhost)
	by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id i57JAO818187;
	Mon, 7 Jun 2004 15:10:24 -0400
X-Authentication-Warning: skysrv.pha.jhu.edu: budavari owned process doing -bs
Date: Mon, 7 Jun 2004 15:10:24 -0400 (EDT)
From: Tamas Budavari <budavari@pha.jhu.edu>
To: Doug Tody <dtody@nrao.edu>
cc: dal@ivoa.net, Pierre Didelon <pdidelon@cea.fr>,
   Laszlo Dobos <dobos@pha.jhu.edu>
Subject: Re: Spectrum Data Model Implementation
In-Reply-To: <Pine.LNX.4.53.0406071239540.2738@colorado.tuc.noao.edu>
Message-ID: <Pine.LNX.4.44.0406071504200.17635-100000@skysrv.pha.jhu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Tamas Budavari <budavari@pha.jhu.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Hi Doug,

> Note that V0.5 is the pre-Interop version, and does not yet reflect the
> discussions we had at the Interop meetings.  It is the most recent version
> currently available though.

I see. Maybe we'll wait for the version with the Boston feedbacks.
Do you know when that would be available for us to implement?

> For a SED there is a SED descriptor object plus 1 or more Spectrum or
> timeSeries objects (the SED segments).  Note there is a distinction between
> SED, Spectrum, and TimeSeries services - they are based on the same data
> model but are distinct services.  Hence if you are implementing a Spectrum
> service, you do not have to know about SEDs, and the service can merely
> return a Spectrum object.

Indeed, in fact we also have the SED in there. Sorry and thanks for the
clarification! [It's really hard to read the VOTable version, the pure XML
is more friendly, however even that shouldn't be read by human beings
(only developers sometimes ;-)]

Cheers, T.

From owner-dal@eso.org  Mon Jun  7 21:39:54 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57JdbDZ014786
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 7 Jun 2004 21:39:37 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i57Jdbhp014785
	for dal-outgoing; Mon, 7 Jun 2004 21:39:37 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i57JdWDZ014778
	for <dal@ivoa.net>; Mon, 7 Jun 2004 21:39:33 +0200 (MEST)
Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i57JdVTY007321
	for <dal@ivoa.net>; Mon, 7 Jun 2004 21:39:31 +0200 (CEST)
Received: from 0-1pool5-78.nas1.thornton1.co.us.da.qwest.net ([67.4.5.78] helo=[10.0.1.4])
	by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1BXPxu-0000yA-00; Mon, 07 Jun 2004 12:39:27 -0700
Date: Mon, 7 Jun 2004 13:39:11 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@colorado.tuc.noao.edu
To: Tamas Budavari <budavari@pha.jhu.edu>
cc: dal@ivoa.net, Pierre Didelon <pdidelon@cea.fr>,
   Laszlo Dobos <dobos@pha.jhu.edu>
Subject: Re: Spectrum Data Model Implementation
In-Reply-To: <Pine.LNX.4.44.0406071504200.17635-100000@skysrv.pha.jhu.edu>
Message-ID: <Pine.LNX.4.53.0406071333430.3618@colorado.tuc.noao.edu>
References: <Pine.LNX.4.44.0406071504200.17635-100000@skysrv.pha.jhu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Mon, 7 Jun 2004, Tamas Budavari wrote:
> > Note that V0.5 is the pre-Interop version, and does not yet reflect the
> > discussions we had at the Interop meetings.  It is the most recent version
> > currently available though.
> 
> I see. Maybe we'll wait for the version with the Boston feedbacks.
> Do you know when that would be available for us to implement?

It is probably best to continue to work with what you have been using
(v0.1 I think) until the new version is available.  We will try to have
this by the end of next week.  XML representation issues like defaulting
optional elements or vector vs scalar will be the same for any of these
versions.  Doug



> > For a SED there is a SED descriptor object plus 1 or more Spectrum or
> > timeSeries objects (the SED segments).  Note there is a distinction between
> > SED, Spectrum, and TimeSeries services - they are based on the same data
> > model but are distinct services.  Hence if you are implementing a Spectrum
> > service, you do not have to know about SEDs, and the service can merely
> > return a Spectrum object.
> 
> Indeed, in fact we also have the SED in there. Sorry and thanks for the
> clarification! [It's really hard to read the VOTable version, the pure XML
> is more friendly, however even that shouldn't be read by human beings
> (only developers sometimes ;-)]
> 
> Cheers, T.

From owner-dal@eso.org  Wed Jul  7 13:53:02 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67BqYFL004366
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 7 Jul 2004 13:52:34 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67BqXR6004363
	for dal-outgoing; Wed, 7 Jul 2004 13:52:33 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67BqTFL004339
	for <dal@ivoa.net>; Wed, 7 Jul 2004 13:52:29 +0200 (MEST)
Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67BqSDP015572
	for <dal@ivoa.net>; Wed, 7 Jul 2004 13:52:28 +0200 (CEST)
Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:39217)
	by ppsw-6.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.146]:25)
	with esmtp (Exim 4.34)
	id 1BiAyQ-0006A8-Ok for dal@ivoa.net; Wed, 07 Jul 2004 12:52:26 +0100
Received: from cass123.ast.cam.ac.uk (cass123 [IPv6:2001:630:200:4240:203:baff:fe17:f117])
	by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i67BqQmm026558
	for <dal@ivoa.net>; Wed, 7 Jul 2004 12:52:26 +0100 (BST)
Received: from cass123.ast.cam.ac.uk (localhost [127.0.0.1])
	by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id i67BqQM1012888
	for <dal@ivoa.net>; Wed, 7 Jul 2004 12:52:26 +0100 (BST)
Received: from localhost (gtr@localhost)
	by cass123.ast.cam.ac.uk (8.12.10+Sun/8.12.8/Submit) with ESMTP id i67BqQhd012885
	for <dal@ivoa.net>; Wed, 7 Jul 2004 12:52:26 +0100 (BST)
X-Authentication-Warning: cass123.ast.cam.ac.uk: gtr owned process doing -bs
Date: Wed, 7 Jul 2004 12:52:26 +0100 (BST)
From: Guy Rixon <gtr@ast.cam.ac.uk>
To: dal@ivoa.net
Subject: SIAP details
Message-ID: <Pine.GSO.4.58.0407071246170.12092@cass123.ast.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Guy Rixon <gtr@ast.cam.ac.uk>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi,

I'm implementing a SIAP service and I have some questions about the
specification.

1. How must the URLs for image query and image retreival be related to be
valid?  Currently, I have http://my.server/path/to/siap/queryImage
and http://my.server/path/to/siap/getImage, i.e. the two web methods are
siblings; is this valid?

2. If the implementation does not support the INTERSECT parameter, what
constraints are placed on how I determine the relevant data?  Can I just pick
one of the values of INTERSECT and implement that?

3. How do we deal with lacunarity?  My data has groups of four images with
gaps between them.  Is it OK to check for intersection of the ROI and the
overall footprint and disregard the cases where the ROI falls into one of the
gaps?

4. Is there an official version of the SIAP standard on the IVOA site?  I've
only found

http://us-vo.org/pubs/files/ACF8DE.pdf

Cheers,
Guy

Guy Rixon 				        gtr@ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523

From vomail@eso.org  Wed Jul  7 14:25:01 2004
Return-Path: <vomail@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67COkdT007869;
	Wed, 7 Jul 2004 14:24:47 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i67COkI05624;
	Wed, 7 Jul 2004 14:24:46 +0200 (MEST)
Message-ID: <40EBEBB0.7080306@eso.org>
Date: Wed, 07 Jul 2004 14:25:20 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Guy Rixon <gtr@ast.cam.ac.uk>,
   IVOA Document Coordinator <ivoadoc@ivoa.net>
CC: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: SIAP details
References: <Pine.GSO.4.58.0407071246170.12092@cass123.ast.cam.ac.uk>
In-Reply-To: <Pine.GSO.4.58.0407071246170.12092@cass123.ast.cam.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> 4. Is there an official version of the SIAP standard on the IVOA site?  I've
> only found

Yes.
http://www.ivoa.net/Documents/WD/SIA/SIA.html

Marco:
Could you please add the link to SIA  V1.0 to the 'latest' page?

Cheers,
Markus

From vomail@eso.org  Wed Jul  7 14:46:50 2004
Return-Path: <vomail@eso.org>
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67CkfdT011077;
	Wed, 7 Jul 2004 14:46:41 +0200 (MEST)
Received: from eso.org ([134.171.27.53])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i67CkfI06548;
	Wed, 7 Jul 2004 14:46:41 +0200 (MEST)
Message-ID: <40EBF0BA.7060900@eso.org>
Date: Wed, 07 Jul 2004 14:46:50 +0200
From: "Marco C. Leoni" <mleoni@eso.org>
Reply-To: marco.leoni@eso.org
Organization: Astrophysical Virtual Observatory @ESO
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Markus Dolensky <Markus.Dolensky@eso.org>,
   IVOA Data Access Layer <dal@ivoa.net>
CC: IVOA Document Coordinator <ivoadoc@ivoa.net>
Subject: Re: SIAP details
References: <Pine.GSO.4.58.0407071246170.12092@cass123.ast.cam.ac.uk> <40EBEBB0.7080306@eso.org>
In-Reply-To: <40EBEBB0.7080306@eso.org>
Content-Type: multipart/alternative;
 boundary="------------000808050700050705080708"
X-Virus-Scanned: by amavisd-new
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

This is a multi-part message in MIME format.
--------------000808050700050705080708
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Done!
The record was already in the submission log, but not in the WD section.


Cheers,
    Marco



Markus Dolensky wrote:

>> 4. Is there an official version of the SIAP standard on the IVOA 
>> site?  I've
>> only found
>
>
> Yes.
> http://www.ivoa.net/Documents/WD/SIA/SIA.html
>
> Marco:
> Could you please add the link to SIA  V1.0 to the 'latest' page?
>
> Cheers,
> Markus


--------------000808050700050705080708
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000066" bgcolor="#ffffff">
<font face="Arial">Done!<br>
The record was already in the submission log, but not in the WD section.<br>
<br>
<br>
Cheers,<br>
&nbsp;&nbsp;&nbsp; Marco<br>
<br>
<br>
</font><br>
Markus Dolensky wrote:<br>
<blockquote type="cite" cite="mid40EBEBB0.7080306@eso.org">
  <blockquote type="cite">4. Is there an official version of the SIAP
standard on the IVOA site?&nbsp; I've
    <br>
only found
    <br>
  </blockquote>
  <br>
Yes.
  <br>
<a class="moz-txt-link-freetext" href="http://www.ivoa.net/Documents/WD/SIA/SIA.html">http://www.ivoa.net/Documents/WD/SIA/SIA.html</a>
  <br>
  <br>
Marco:
  <br>
Could you please add the link to SIA&nbsp; V1.0 to the 'latest' page?
  <br>
  <br>
Cheers,
  <br>
Markus</blockquote>
</body>
</html>

--------------000808050700050705080708--

From owner-dal@eso.org  Wed Jul  7 16:27:46 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67ERPdT023868
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 7 Jul 2004 16:27:25 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67ERP2D023867
	for dal-outgoing; Wed, 7 Jul 2004 16:27:25 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67ERLdT023855
	for <dal@ivoa.net>; Wed, 7 Jul 2004 16:27:22 +0200 (MEST)
Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67ERJDP020401
	for <dal@ivoa.net>; Wed, 7 Jul 2004 16:27:20 +0200 (CEST)
X-Envelope-From: rplante@poplar.ncsa.uiuc.edu
Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122])
	by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id i67ERBV21615;
	Wed, 7 Jul 2004 09:27:11 -0500
Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1])
	by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id i67ERBWh021153;
	Wed, 7 Jul 2004 09:27:11 -0500
Received: from localhost (rplante@localhost)
	by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id i67ERAgb021149;
	Wed, 7 Jul 2004 09:27:10 -0500
Date: Wed, 7 Jul 2004 09:27:10 -0500 (CDT)
From: Ray Plante <rplante@ncsa.uiuc.edu>
To: Guy Rixon <gtr@ast.cam.ac.uk>
cc: dal@ivoa.net
Subject: Re: SIAP details
In-Reply-To: <Pine.GSO.4.58.0407071246170.12092@cass123.ast.cam.ac.uk>
Message-ID: <Pine.LNX.4.44.0407070922030.5269-100000@poplar.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information
X-NCSA-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ray Plante <rplante@ncsa.uiuc.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Wed, 7 Jul 2004, Guy Rixon wrote:
> 1. How must the URLs for image query and image retreival be related to be
> valid?  Currently, I have http://my.server/path/to/siap/queryImage
> and http://my.server/path/to/siap/getImage, i.e. the two web methods are
> siblings; is this valid?

Yes.  I presume that the getImage URL will include, say, a ? and necessary 
parameters to get that particular image described by that row.  All of 
that must appear in the reference URL.  

> 2. If the implementation does not support the INTERSECT parameter, what
> constraints are placed on how I determine the relevant data?  Can I just pick
> one of the values of INTERSECT and implement that?

Yes.  

> 3. How do we deal with lacunarity?  My data has groups of four images with
> gaps between them.  Is it OK to check for intersection of the ROI and the
> overall footprint and disregard the cases where the ROI falls into one of the
> gaps?

Yes.

hope this helps,
Ray


From owner-dal@eso.org  Wed Jul  7 17:25:37 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67FPBdT002121
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 7 Jul 2004 17:25:11 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i67FPBOp002117
	for dal-outgoing; Wed, 7 Jul 2004 17:25:11 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i67FP2dT002092
	for <dal@ivoa.net>; Wed, 7 Jul 2004 17:25:02 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i67FP0DP022362
	for <dal@ivoa.net>; Wed, 7 Jul 2004 17:25:01 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i67FOlRo031903;
	Wed, 7 Jul 2004 09:24:48 -0600
Date: Wed, 7 Jul 2004 09:24:46 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Guy Rixon <gtr@ast.cam.ac.uk>
cc: dal@ivoa.net
Subject: Re: SIAP details
In-Reply-To: <Pine.GSO.4.58.0407071246170.12092@cass123.ast.cam.ac.uk>
Message-ID: <Pine.LNX.4.44.0407070917570.1814-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.1.0.84332
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Wed, 7 Jul 2004, Guy Rixon wrote:

> 1. How must the URLs for image query and image retreival be related to be
> valid?  Currently, I have http://my.server/path/to/siap/queryImage
> and http://my.server/path/to/siap/getImage, i.e. the two web methods are
> siblings; is this valid?

The acref URL (for the getImage) can be anything as long as it fetches
the image described in the query response.  It does not have to be
related to the base URL for the query method, although in implementation
terms it often is.
 
> 2. If the implementation does not support the INTERSECT parameter, what
> constraints are placed on how I determine the relevant data?  Can I just pick
> one of the values of INTERSECT and implement that?

Yes.  In general you err on the side of including candidate images and
let the client sort out the query response.
 
> 3. How do we deal with lacunarity?  My data has groups of four images with
> gaps between them.  Is it OK to check for intersection of the ROI and the
> overall footprint and disregard the cases where the ROI falls into one of the
> gaps?

It is ok, but if there is actually no data in the ROI then probably you
should omit the image.

Consider implementing a cutout service if your images are large.
 
> 4. Is there an official version of the SIAP standard on the IVOA site?  I've
> only found
> 
> http://us-vo.org/pubs/files/ACF8DE.pdf

Yes, SIAP is on the IVOA site under "documents".  The URL is

    http://www.ivoa.net/Documents/WD/SIA/SIA.html

Doug

From owner-dal@eso.org  Fri Aug  6 18:40:14 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i76GdHSk003199
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 6 Aug 2004 18:39:17 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i76GdH9K003198
	for dal-outgoing; Fri, 6 Aug 2004 18:39:17 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i76Gd6Sk003184;
	Fri, 6 Aug 2004 18:39:07 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i76Gd6I17052;
	Fri, 6 Aug 2004 18:39:06 +0200 (MEST)
Message-ID: <4113B415.3040808@eso.org>
Date: Fri, 06 Aug 2004 18:38:45 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dtody@aoc.nrao.edu
CC: dal@ivoa.net
Subject: Re: SSAmples
References: <200408061403.i76E3pj7008188@urania.cfa.harvard.edu>
In-Reply-To: <200408061403.i76E3pj7008188@urania.cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Jonathan McDowell wrote:
 > Doug, Markus:
 >  I have updated and improved my VOTable example serialization,
 > see the 2004 Aug 5 draft in
 > http://hea-www.harvard.edu/~jcm/vo/docs/spec.html
 > I hope this is closer to what we need. I'm still working on
 > generating a real life set of examples from my quasar spectral archive.
 >  - Jonathan


Hello Doug and Jonathan,

A SSAmple file containing 3 segments (SED point, 1d Spectrum, time series) is 
on the Wiki:
http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample1.xml

The actual values were made up or were taken from the example given in the 
Spectral DM draft. I'll look at an example from NED as a next step.

Jonathan:
I was almost done with this based on the previous DM version dated Aug. 5 and 
so my comments do not refer to today's update. I noticed that you've fixed a 
couple of things like the PARAM syntax already. Hence, simply ignore related 
obsolete comments.

Also, the new STC was not taken into account and I'm open to suggestions how to 
map it to VOTable speak. Nonetheless, there are a number of points that the 
sample should help to address in its current form (below).

Thank you for your input.

Greetings,
Markus


******************


I. Inconsistencies between DM V0.9 and SSA interface as of Boston in May
========================================================================

1. Target.CreationType values {Archival, Dynamic, Custom} in DM differ from
    SSA interface Sed.CreationType {Atlas, Virtual}. My sample sticks to the DM
    assuming that "Atlas" maps to "Archival" and "Virtual" to "Dynamic+Custom".
2. Target.pos exists in the DM only. Presumably this is the search position, 
whereas each segment has an actual pointing/object position?
3. SNR is in object "Derived" in the DM and not in "Target"
4. Flux.Npts is missing in the DM. We probably don't need it(?)
5. SpectralCoord.deReddened and SpectralCoord.correlated are missing; These 
things could go into a new object SpectralCoord.Quality or is this what 
CustomParams is about?
6. DM has a Location object in each Segment rather than a global one in the 
Target object. My SSAmple sticks to the DM.



II. Further Comments/Errata
===========================

a)
the value attribute of a PARAM element is supposed to contain the datum; hence 
the value attribute is mandatory; all PARAM elements need to be modified 
accordingly

b)
a vector can be expressed as a space separated list but not comma separated as 
in PARAM Coverage.Location.Sky

c)
GROUPing works differently: use PARAMref and FIELDref; all GROUP elements need 
to be modified accordingly

d)
in VOTable examples UCD words are colon separated instead of semicolon separated

e)
Coverage.Extent.Time is given as time.expo in table 5.1 and time.interval in 
the sample VOTable
One could allow both, of course: time.expo for the net exposure time and 
time.interval denotes the difference between start time of the first exposure 
and the end time of the last subexposure.

f)
Why are "Sky" and "Time" encoded as subGROUPs in object "Coverage.Location" 
instead of PARAM elements? In other words, why does Extent and Location have a 
different substructure although they are similarly defined in table 5.1?

g)
DataID.Date: append "Z" for UT to time string; according to ISO standard it's 
considered local time otherwise

h)
If Target is contained in the SED object then the utypes should be SED.Target.* 
instead of Target.*

i)
Was it intentional to define Target.VarAmpl (src.var.amplitude) as well as 
Derived.VarAmpl (stat.ampl)?

j)
How about defining Flux.Quality using the VALUES/OPTION element (see example)?
Given this encoding is there really a need for Flux.Quality.N with n={0,1, 
...}? Or, is the intention to combine quality flags? If so, how?

k)
We do lack suitable utypes for the TABLE element in order to define the type of 
Segment that follows: { Sed, Spectrum, TimeSeries }
"Spectrum" as the utype of the 1st table is ambiguous since the root object is 
SED in the DM diagram

l)
Does the percent "%" in %Contact and %Contact.Email have a particular meaning?
Can we remove the dot in Contact(.)Email ?

m)
More generally, how about removing dots in field names?
SED.Bandpass.Min => SED.BandpassMin
SED.Bandpass.Max => SED.BandpassMax

n)
The closing TR elements are missing in TABLEDATA of the DM sample

o)
replace "Barycentric" by 8-char tag "Barycent" in sample VOTable in the DM doc


III. Suggestions for assignment of UCDs
=======================================
SED.NSegments		  meta.number (instead of arith.factor)
SED.SegmentType	          meta.code
# move CreationType to DataID object, otherwise model and observational data 
cannot be combined in one VOTable doc.
SpectralCoord.deReddened  meta.code.qual
SpectralCoord.correlated  meta.code.qual
Spatial.Resolution	  instr.ang-res
Time.Accuracy.BinSize	  time.period

reference:
http://vizier.u-strasbg.fr/UCD/lists/ucd1p-words-20040520.txt

From owner-dal@eso.org  Tue Aug 10 03:30:54 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7A1MnNU005047
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 10 Aug 2004 03:22:49 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i7A1Mnsb005046
	for dal-outgoing; Tue, 10 Aug 2004 03:22:49 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7A1MkNU005041;
	Tue, 10 Aug 2004 03:22:46 +0200 (MEST)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i7A1MhFA023334;
	Tue, 10 Aug 2004 03:22:44 +0200 (CEST)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id i7A1MfR5022562;
	Mon, 9 Aug 2004 21:22:41 -0400 (EDT)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id i7A1MeVf014155;
	Mon, 9 Aug 2004 21:22:40 -0400 (EDT)
Date: Mon, 9 Aug 2004 21:22:40 -0400 (EDT)
Message-Id: <200408100122.i7A1MeVf014155@urania.cfa.harvard.edu>
To: Markus.Dolensky@eso.org, dal@ivoa.net, dtody@aoc.nrao.edu
Subject: Re: SSAmples
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.8.9.109970
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Markus wrote:
> Hello Doug and Jonathan,

Hi Markus, I have taken a look at your comments and modified

http://hea-www.harvard.edu/~jcm/vo/docs/spec.html

in an attempt to respond to them. Detailed replies below.
I have also modified the xml schema slightly and made an
XML instance example that is equivalent to the VOTABLE 
instance, in an attempt to show how one might perform
the equivalence mapping between the 'pure xml' and VOTABLE
representations both in this case and in a general way.
I'm not sure what I have done is even close to workable, so
I hope you and Doug and Tamas will take a good look.

I've tried to get my VOTABLE instance up to the latest definition.
I note in your sample example you use PARAMref; I don't see why this
is a good idea, it seems to be redundant since PARAM is allowed directly
within a GROUP, so I've stayed with not using PARAMref.


The older versions are now at

http://hea-www.harvard.edu/~jcm/vo/docs/spec040805.html
http://hea-www.harvard.edu/~jcm/vo/docs/spec040719.html

> 
> Also, the new STC was not taken into account and I'm open to suggestions how to 
> map it to VOTable speak. Nonetheless, there are a number of points that the 

I plan to look at this soon; let's defer that until we have the rest sorted out.



> I. Inconsistencies between DM V0.9 and SSA interface as of Boston in May
> ========================================================================

These are really mostly inconsistencies between DM V0.9 and
the "Data Model Summary (May 20)" in Doug's email which also summarized
the SSA interface.

 
> 1. Target.CreationType values {Archival, Dynamic, Custom} in DM differ from
>     SSA interface Sed.CreationType {Atlas, Virtual}. My sample sticks to the DM
>     assuming that "Atlas" maps to "Archival" and "Virtual" to "Dynamic+Custom".

Yes, I think Doug changed these names to the new (DM) values, possibly to 
better match SIAP?

> 2. Target.pos exists in the DM only. Presumably this is the search position, 
> whereas each segment has an actual pointing/object position?
> 6. DM has a Location object in each Segment rather than a global one in the 
> Target object. My SSAmple sticks to the DM.

Well, I would say the object has an actual position, and this is what I
intend by target.pos. It's true that as well as this, each segment has
an actual pointing position, or more accurately an actual pointing field
of view that we integrate over; these are given in the Coverage.Location
(and Coverage.Region) for each segment. As you imply, you can't
guarantee that the Location is the same for each Segment.

Another comment on Target: the whole first table giving the global info,
including Target, is only a table because you're not allowed to have
GROUP elements directly under RESOURCE. It would be cleaner if you could
just eliminate the first <TABLE> and </TABLE> and have those PARAM and
GROUP values directly under RESOURCE. Is the reason VOTable doesn't
allow this that GROUPs could potentially include FIELDS?


> 3. SNR is in object "Derived" in the DM and not in "Target"

Right. It was in "Target" in Doug's "Data Model Summary".
But it's really a derived data quantity, and when we get a catalog
data model we'll want that connection.

> 4. Flux.Npts is missing in the DM. We probably don't need it(?)

I agree - I think applications can derive it trivially.

> 5. SpectralCoord.deReddened and SpectralCoord.correlated are missing; These 
> things could go into a new object SpectralCoord.Quality or is this what 
> CustomParams is about?

The "dereddened" is a particularly significant issue, because it is one
of a whole family of possible annotations which really qualify the UCD.
It helps answer the question "What are these numbers", you can either
think of it as  "What corrections have been applied to the data" or you
might think of it as "Is this the SED as it hits the Earth's atmosphere
or is it the SED measured just outside the source?". The first way of
thinking is related to provenance, the second way of thinking is closer
to UCD. 

I propose that we NOT include these in version 1.0 of the SSAP, pending
further discussion of the bigger issue.

One important issue I pull out here:

> If Target is contained in the SED object then the utypes should be SED.Target.* 
> instead of Target.*

So, I have made the assumption that the syntax for UTYPE should be:

- we define a namespace, xmlns:NS=URI which defines a model for an object foo
  containing various subobjects
- a fully qualified utype is of the form
   NS:foo.a.b.c.d  where a,b,c,d are subobjects in the hierarchy
BUT (I propose)
- if a GROUP, RESOURCE or TABLE element has utype = NS:foo.a.b
  and if that element contains other elements (e.g. GROUP, PARAM, FIELD)
  and if those elements have a type   NS:c.d 
  whose leading element is not foo, then the context is taken
  from the enclosing element and NS:c.d is resolved to NS:foo.a.b.c.d
 
  Thus in the example given GROUP utype="sed:Target" is inside TABLE utype="sed:SED"
  and is understood to refer to that context, i.e. Target = SED.Target

Should we have this or a similar 'relative utype path' convention?
Is this good xml? Or do we require a full utype path for every utype?
I know Doug expressed a desire that the full path not be required.


> II. Further Comments/Errata
> ===========================
> 
> a)
> the value attribute of a PARAM element is supposed to contain the datum; hence 
> the value attribute is mandatory; all PARAM elements need to be modified 
> accordingly

Fixed


> b)
> a vector can be expressed as a space separated list but not comma separated as 
> in PARAM Coverage.Location.Sky

Fixed

> 
> c)
> GROUPing works differently: use PARAMref and FIELDref; all GROUP elements need 
> to be modified accordingly

Fixed

> 
> d)
> in VOTable examples UCD words are colon separated instead of semicolon separated

Fixed.

> 
> e)
> Coverage.Extent.Time is given as time.expo in table 5.1 and time.interval in 
> the sample VOTable
> One could allow both, of course: time.expo for the net exposure time and 
> time.interval denotes the difference between start time of the first exposure 
> and the end time of the last subexposure.

Settled on time.expo.

> 
> f)
> Why are "Sky" and "Time" encoded as subGROUPs in object "Coverage.Location" 
> instead of PARAM elements? In other words, why does Extent and Location have a 
> different substructure although they are similarly defined in table 5.1?

The idea was that these would be later extended to have accuracy values.
But we'll keep them PARAM for now to be consistent with the xsd schema.


> 
> g)
> DataID.Date: append "Z" for UT to time string; according to ISO standard it's 
> considered local time otherwise

ok

> 
> h)
> If Target is contained in the SED object then the utypes should be SED.Target.* 
> instead of Target.*

See discussion above.


> i)
> Was it intentional to define Target.VarAmpl (src.var.amplitude) as well as 
> Derived.VarAmpl (stat.ampl)?

Yes (I think). The first is from some external source giving background
context to the obs, the second is from the current dataset saying
what the variation is in *this* data.

> 
> j)
> How about defining Flux.Quality using the VALUES/OPTION element (see example)?
> Given this encoding is there really a need for Flux.Quality.N with n={0,1, 
> ...}? Or, is the intention to combine quality flags? If so, how?

I'm not enthusiastic about the use of the VALUES/OPTION, personally.
Particularly for things like BARYCENT it seems like overkill to list all the options
in each document instance.  

In the particular case of Quality, I'm not sure what you mean by "combine quality
flags". But I think the intention is to have

<GROUP utype="Quality">
 <PARAM name="WaveQuality" utype="Quality.1" ucd="meta.code.qual;em.wl" value="1">
  <DESCRIPTION>Quality flag for wavelength value</DESCRIPTION>
 <PARAM name="AstrometricQuality" utype="Quality.2" ucd="meta.code.qual;pos.eq" value="4">
  <DESCRIPTION>Quality flag for astrometric solution</DESCRIPTION>
</GROUP>

with no overall single integer "quality value".

> 
> k)
> We do lack suitable utypes for the TABLE element in order to define the type of 
> Segment that follows: { Sed, Spectrum, TimeSeries }
> "Spectrum" as the utype of the 1st table is ambiguous since the root object is 
> SED in the DM diagram

The utype is  SED.Spectrum; the model is the same for spectrum, photometry, time series
so the utype is the same. We should use a UCD or an attribute to distinguish the cases. 
I have added a SegmentType parameter to the Segment object.

> 
> l)
> Does the percent "%" in %Contact and %Contact.Email have a particular meaning?
> Can we remove the dot in Contact(.)Email ?

The percent came from some earlier version of the registry doc. The new version
of the doc has Contact as an object with two sub members and I have made this fix.

> 
> m)
> More generally, how about removing dots in field names?
> SED.Bandpass.Min => SED.BandpassMin
> SED.Bandpass.Max => SED.BandpassMax

There's a real difference here: SED.Bandpass.Min implies that there
is an SED.Bandpass object which may have new fields added to it later.
I've changed it to BandpassMin since we don't have such an object yet.

> 
> n)
> The closing TR elements are missing in TABLEDATA of the DM sample

ok


> 
> o)
> replace "Barycentric" by 8-char tag "Barycent" in sample VOTable in the DM doc

ok

> 
> 
> III. Suggestions for assignment of UCDs
> =======================================
> SED.NSegments		  meta.number (instead of arith.factor)

ok 

> SED.SegmentType	          meta.code

ok

> # move CreationType to DataID object, otherwise model and observational data 
> cannot be combined in one VOTable doc.

OK

> SpectralCoord.deReddened  meta.code.qual
> SpectralCoord.correlated  meta.code.qual

ok, modulo issues about the items themselves.

> Spatial.Resolution	  instr.ang-res

ok - although it may not be instrumental resolution (could be resampled)

> Time.Accuracy.BinSize	  time.period

oooh... I know what you are saying but UCD=time.period doesn't make me think
of a bin size. Perhaps I could live with  "time.period;instr".

Thanks!!
 Jonathan

From owner-dal@eso.org  Tue Aug 10 20:47:39 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7AIlCNU019616
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 10 Aug 2004 20:47:12 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i7AIlCup019615
	for dal-outgoing; Tue, 10 Aug 2004 20:47:12 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7AIl2NU019558;
	Tue, 10 Aug 2004 20:47:02 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i7AIl2I09635;
	Tue, 10 Aug 2004 20:47:02 +0200 (MEST)
Message-ID: <41191811.20404@eso.org>
Date: Tue, 10 Aug 2004 20:46:41 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
CC: dal@ivoa.net
Subject: Re: SSAmples
References: <200408100122.i7A1MeVf014155@urania.cfa.harvard.edu>
In-Reply-To: <200408100122.i7A1MeVf014155@urania.cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Jonathan,

We're already down to only 2 out of some 30 items after a single iteration:

> [...] it seems to be redundant since PARAM is allowed directly
> within a GROUP, so I've stayed with not using PARAMref.

Section 4.7 of the VOTable spec says
(http://www.ivoa.net/Documents/PR/VOTable/VOTable-20040608.html#ToC31)

"... However, in order to avoid any confusion with the previous version of 
VOTable which did not know the GROUP, all FIELDs are always defined outside any 
group, and the GROUP designates its member fields via FIELDref elements."

It seems above rule prevents FIELDs in a GROUP (and hence also PARAM which in 
the SSA context it is the special case of a constant column like an invariant 
systematic error). Otherwise, I would support your approach.


 > In the particular case of Quality, I'm not sure what you mean
 > by "combine quality flags".

The question was whether Quality is a single value/cell comprised of N integers 
that are concatenated somehow similar to a bit mask, or whether there are N 
separate boolean values/cells.

Your example shows that the latter is the case.

Clarified.

 > <GROUP utype="Quality">
 >  <PARAM name="WaveQuality" utype="Quality.1" ucd="meta.code.qual;em.wl" 
value="1">
 >   <DESCRIPTION>Quality flag for wavelength value</DESCRIPTION>
 >  <PARAM name="AstrometricQuality" utype="Quality.2" 
ucd="meta.code.qual;pos.eq" value="4">
 >   <DESCRIPTION>Quality flag for astrometric solution</DESCRIPTION>
 > </GROUP>

Markus









From owner-dal@eso.org  Wed Aug 11 05:57:46 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7B3v6Rd000061
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 11 Aug 2004 05:57:07 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i7B3v6Ct000060
	for dal-outgoing; Wed, 11 Aug 2004 05:57:06 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7B3v3Rd000054;
	Wed, 11 Aug 2004 05:57:03 +0200 (MEST)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i7B3v1Gd016867;
	Wed, 11 Aug 2004 05:57:02 +0200 (CEST)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id i7B3v0CH028752;
	Tue, 10 Aug 2004 23:57:00 -0400 (EDT)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id i7B3uxdI016187;
	Tue, 10 Aug 2004 23:56:59 -0400 (EDT)
Date: Tue, 10 Aug 2004 23:56:59 -0400 (EDT)
Message-Id: <200408110356.i7B3uxdI016187@urania.cfa.harvard.edu>
To: dal@ivoa.net, markus.dolensky@eso.org
Subject: Re: SSAmples
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.8.10.110065
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Markus,

 I'm going to try and hold out against this latest one:

> "... However, in order to avoid any confusion with the previous version of 
> VOTable which did not know the GROUP, all FIELDs are always defined outside any 
> group, and the GROUP designates its member fields via FIELDref elements."
> 
> It seems above rule prevents FIELDs in a GROUP (and hence also PARAM which in 
> the SSA context it is the special case of a constant column like an invariant 
> systematic error). Otherwise, I would support your approach.

I guess I don't really see the point. If it's constant, use a PARAM within
the group. If it's a column, use a FIELDref within the group. I don't think
this presents a particular parsing problem.

(Also, for what it's worth,
 most of the PARAMs are not in the category of things that might sometimes be FIELDs.)


  - Jonathan

From owner-dal@eso.org  Wed Aug 11 12:26:29 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7BAPrRd001006
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 11 Aug 2004 12:25:53 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.6/8.12.6/Submit) id i7BAPr4q001005
	for dal-outgoing; Wed, 11 Aug 2004 12:25:53 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.6/8.12.6) with ESMTP id i7BAPhRd000977;
	Wed, 11 Aug 2004 12:25:43 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i7BAPhI27994;
	Wed, 11 Aug 2004 12:25:43 +0200 (MEST)
Message-ID: <4119F412.6050605@eso.org>
Date: Wed, 11 Aug 2004 12:25:22 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
CC: dal@ivoa.net
Subject: Re: SSAmples
References: <200408110356.i7B3uxdI016187@urania.cfa.harvard.edu>
In-Reply-To: <200408110356.i7B3uxdI016187@urania.cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> I guess I don't really see the point. If it's constant, use a PARAM within
> the group. If it's a column, use a FIELDref within the group.

Ah, a mixed approach: Since VOTable allows this it's ok, of course.
I tend to use FIELD(ref) and PARAM(ref) symmetric, but that's a just a personal 
convention and I don't want to impose this on anybody else.

Clarified.

> Another comment on Target: the whole first table giving the global info,
> including Target, is only a table because you're not allowed to have
> GROUP elements directly under RESOURCE. It would be cleaner if you could
> just eliminate the first <TABLE> and </TABLE> and have those PARAM and
> GROUP values directly under RESOURCE. Is the reason VOTable doesn't
> allow this that GROUPs could potentially include FIELDS?

In future versions we might have FIELD elements also in the global section. So, 
for the sake of extensibility I don't mind wrapping global parameters into a TABLE.

Markus

From owner-dm@eso.org  Tue Sep 21 14:20:39 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LCK4gx001002
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 21 Sep 2004 14:20:04 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8LCK4dg001001
	for dm-outgoing; Tue, 21 Sep 2004 14:20:04 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LCK3gx000997;
	Tue, 21 Sep 2004 14:20:03 +0200 (MEST)
Received: from gannet.scg.man.ac.uk (gannet.scg.man.ac.uk [130.88.94.110])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LCK2qH025827;
	Tue, 21 Sep 2004 14:20:02 +0200 (CEST)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by gannet.scg.man.ac.uk with esmtp (Exim 4.20)
	id 1C9jci-000Pgr-F7; Tue, 21 Sep 2004 13:19:56 +0100
Received: from [130.88.24.148] (helo=adikia)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1C9jci-0004N7-00; Tue, 21 Sep 2004 13:19:56 +0100
Date: Tue, 21 Sep 2004 13:19:56 +0100 (BST)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@adikia
To: dal@ivoa.net, dm@ivoa.net
Subject: Comments on Spectrum Data Model 0.9
Message-ID: <Pine.GSO.4.53.0409211318390.11409@adikia>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1C9jci-000Pgr-F7*5papb6aXat2*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.21.0
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


Hello,

It looks really good and I was pleased to see that this relates to
other Data Models, I have not done a full check for consistency but
that sort of thing gives me conficence that it is designed to be
used.  I am also impressed by the coverage of errors etc.

I am still having trouble figuring out what parts of the model are
intended to apply per data set and which parts are per data point.  By
analogy, I would expect that the Obs. data model could describe a data
cube of images with a single set of metadata, if each plane of the
image was the same apart from its content.  Of couse, the local
statistical noise might be different in each plane but then in a
single image it might be differnt in diffeernt regions and we don;t
use different metadata for each pixel.

As I understand it, the Spectrum model suggests that each spectral
point, has centre, max and min of bin in spectral units (and other
metadata) and that is indeed required for some SEDs e.g. as provided
by NED.

But in fact some IVOA examples given just give centre of bin e.g. for
many samples which are equally spaced in the specified units.  In that
case it would be useful to have the (constant) bin width in the header
to aid extracting metadata for the Obs DM, Registry etc.  Will this be
covered under Resolution?  Moreover, other parameters such as the
available errors may be constant for the whole data set (or each point
may have its own errors).

i.e., I want to be able to get at information which says "Spectrum of
BigSupernova from 1719 to 1721 MHz in 2048 equal-sized channels"
which may then be a FITS file or ascii etc.  with a header which gives
the metadata which are common to every spectral point but the data
itself is just a series of pairs of frequencies and flux densities.

If we are talking about e.g. 50 separate monitoring observations in
512 channels x 4 polarizations, all repeated for 10 surces, the
difference between using 2 numbers for each spectral point and about 6
starts to become significant when constructing spectra on the fly,
returning lots of spectra, trawling metadata or just intimidating the
user/data provider.


There are more difficult situations - I am not arguing that they
should all be covered now, but which are and which are we deferring?

I am assuming in the above that the data have been fully calibrated
and there is not a separate bandpass function (i.e. sensitivity
changes with frequency) but that is not always the case.  In any event
the user might want access to the bandpass correction function which
had been applied which might be a mathematical function or a look-up
table.  Data may be stored in other formats e.g. all the spectral
coordinate information in the header and just a table with pairs of
values for channel No and flux density, or even a single vector of
flux densities.

It seems to me that, at present, a lot of data providers will have
some hard work to provide conformant data.  That is not necessarily an
argument against the model (apart from the unneccesary bloat with I
will continue to heckle about!) but it does suggest that it might be
useful to define a very few aspects as "must" and offer help in
sorting out the rest.  I would rather see that, than use alternative
`simplified' models like the Dobos-Budvari schema (Sect. 8.5) -
although some such simplification might be useful if in fact some
aspects of e.g. Coverage do actually belong in the Obs data model and
should be provided by a link rather than duplicated.  There are
problems with the Dobos-Budvari schema as it stands, e.g. it is a
nightmare trying to manipulate a spectrum equally spaced in frequency
if you can only use wavelength units, although the latter might be
adequate for the Registry.

For the most recent/future data sets, I see that it model is applied
to SDSS; what do other people think, e.g. ISO, ALMA?  I would also
like to know what Ivo Busko (SpecView designer) makes of it.

cheers
a





- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).

From owner-dal@eso.org  Tue Sep 21 15:55:56 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LDtogx016270
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 21 Sep 2004 15:55:50 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8LDtoC4016268
	for dal-outgoing; Tue, 21 Sep 2004 15:55:50 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LDthgx016245;
	Tue, 21 Sep 2004 15:55:43 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i8LDthI02132;
	Tue, 21 Sep 2004 15:55:43 +0200 (MEST)
Message-ID: <415032CF.3010904@eso.org>
Date: Tue, 21 Sep 2004 15:55:27 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>, Doug Tody <dtody@nrao.edu>
CC: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: SSAmples
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Jonathan and Doug,

To pick up the string here's a new version of the 'ssample' file:
http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample1.xml

Apart from the changes discussed in August 
(http://www.ivoa.net/forum/dal/0408/date.htm) the following bits are open:


1) inclusion of STC

2) my suggestion to use absolute UTYPES to enhance readibility and simplify parsing
   Doug?

3) apparently SegmentType "composite" was replaced by "Photometry":
Is this making my example which combines SED, 1dSpectrum and a time series 
invalid or is "Photometry" purely a different label for "composite"?

4) Clarification bout VALUES/OPTION in PARAM/FIELD:
It belongs to the metadata response which is out of scope of this discussion. 
They're in the sample file as in-line documentation making it easier to take 
those files as templates when creating new services. Other than that those 
elements are optional.

***

About VOTable sample in http://hea-www.harvard.edu/~jcm/vo/docs/spec.html:

5) FIELDref.ref is linked to FIELD.name instead of FIELD.ID

6) DataID.DataDate is used instead of DataID.Date as in table of section 5.5 of 
http://hea-www.harvard.edu/~jcm/vo/docs/spec.html

Greetings,
Markus

From owner-dal@eso.org  Tue Sep 21 18:02:35 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LG2Ugx003704
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 21 Sep 2004 18:02:30 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8LG2UMG003703
	for dal-outgoing; Tue, 21 Sep 2004 18:02:30 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LG2Tgx003696;
	Tue, 21 Sep 2004 18:02:29 +0200 (MEST)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8LG2Re2003822;
	Tue, 21 Sep 2004 18:02:28 +0200 (CEST)
Received: from stsci.edu (obiwan.stsci.edu [130.167.236.123])
	by donner.stsci.edu (MOS 3.4.8-GR)
	with ESMTP id AUR11751;
	Tue, 21 Sep 2004 12:02:21 -0400 (EDT)
Message-ID: <415050A7.8F50891E@stsci.edu>
Date: Tue, 21 Sep 2004 12:02:47 -0400
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anita Richards <amsr@jb.man.ac.uk>
CC: dal@ivoa.net, dm@ivoa.net
Subject: Re: Comments on Spectrum Data Model 0.9
References: <Pine.GSO.4.53.0409211318390.11409@adikia>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Junkmail-Status: score=0/50, host=donner.stsci.edu
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.21.0
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ivo Busko <busko@stsci.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Anita Richards wrote:
<snip>
> to SDSS; what do other people think, e.g. ISO, ALMA?  I would also
> like to know what Ivo Busko (SpecView designer) makes of it.
<snip>

I also liked the model very much. Seems to be very
complete.

My reading is biased towards the spectral formats I 
implemented in specview, so I may have missed potential
problems in parts of the model that do not relate
specifically with what specview can do. For instance,
there is nothing in specview to deal with time
dependencies, thus I cannot say much on that regard
from a practical, implementation viewpoint.

I attempted to "fit" the spectral formats implemented in
specview into the model, and not a single one failed to
do so. I could have used such a model, if it were available
5 years ago or so, to completely design the specview
Spectum interface from scratch. As a matter of fact, I can
use it now to add new capabilities not supported yet, such
as variable resolution...

Well, there is a single minor point where the model and
the "real data" I used disagree: data providers usually
do not care to calibrate the background data to flux 
density units. The few formats that allow for a background
array (STIS, IUE, ACS) provide then in some sort of raw
counts. Thus if the requirement in paragraph 4.4 of the
model document is to be enforced, these spectra must be
delivered without the background array. Unless the data
provider adds an extra "calibration step" at the delivery
point (if feasible).

As for the main issue addressed by Anita: I don't see the
apparent redundancy in information content as a problem,
IF a solution based on WebServices (or equivalent) technology
is adopted by both providers and consumers. In that light the
Spectrum Data Model can be considered as describing an 
interface, not an implementation. Other issues addressed by
Anita can all be handled in such a framework as well.

Thus in the example of a spectrum where the resolution, say,
is the same for all data points, the delivery (that is, the
thing that actually goes thru the wire) will carry a single
instance of a Resolution element. The interface implemented 
at the receiving end will handle that format transparently to
the consumer code, such that one can still write 

resolution = dataPoint[i].getResolution() 

according to the interface (data model) specs, and get the correct
value for the resolution for each data point i.

However, outside the scope of a webservices infrastructure, 
Anita's concerns are still valid. Presently I wouldn't know
how to handle them.

-Ivo

 *********************************************************************
 *  Ivo C. Busko, PhD                        e-mail: busko@stsci.edu *
 *  Senior Systems Software Engineer                                 *
 *  Science Software Branch                                          *
 *  Engineering and Software Services Division  Voice: (410)338-4472 *
 *  Space Telescope Science Institute             FAX: (410)338-4767 *
 *  3700 San Martin Drive                                            *
 *  Baltimore MD 21218-2410  USA                                     *
 *********************************************************************

From owner-dal@eso.org  Thu Sep 23 04:32:03 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8N2VIxE016429
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 23 Sep 2004 04:31:18 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8N2VIGu016428
	for dal-outgoing; Thu, 23 Sep 2004 04:31:18 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8N2VIxE016424
	for <dal@ivoa.net>; Thu, 23 Sep 2004 04:31:18 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8N2VFSV004958
	for <dal@ivoa.net>; Thu, 23 Sep 2004 04:31:16 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i8N2Us9f025624;
	Wed, 22 Sep 2004 20:30:55 -0600
Date: Wed, 22 Sep 2004 20:30:49 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: dal@ivoa.net
Subject: DAL discussions in Pune
Message-ID: <Pine.LNX.4.44.0409222029300.1315-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c
	on virgo
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.22.3
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

IVOA DAL Working Group
Pune, India 27-29 Sept 2004


Hi DAL Folks -

Here is a draft agenda for the DAL sessions in Pune.


DAL-1  Monday, Sept 27  14:00 - 15:30

    SSA data model V0.9 update (J. McDowell)
	- Includes new data model serializations
    SSA query (M. Dolensky)
	- Formatting the query response VOTable, which is based on
	  mapping elements of the SSA data model into VOTable


DAL-2  Tuesday, Sept 28  11:00 - 12:30

    VOSpec tool demo (P. Osuna)
	- Includes issue of dealing with flux unit conversions in
	  the spectral data model
    SIA extension (P. Fernique for F. Bonnarrel, P. Osuna, et. al.)
	- Metadata extension scheme for adding arbitrary dataset
	  metadata to the DAL query respone (not just for SIA)
    Data Staging in SIA (D. Tody - if there is time)
	- We need to start looking at long-running data access operations
	  and how to manage batch processes in DAL interfaces using
	  asynchronous messaging, polling, data staging, and so forth.


We could also discuss SkyNode and ADQL integration into DAL, however
since the sessions don't overlap this might be better done in the VOQL
session, which immediately follows DAL-1.

A related discussion of data characterization will take place in DM-1,
immediately before DAL-1.  This is an essential element of both SSA and
the next version of SIA.

	- Doug

From owner-dal@eso.org  Thu Sep 23 16:12:32 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8NECS0M025641
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 23 Sep 2004 16:12:28 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8NECSFk025640
	for dal-outgoing; Thu, 23 Sep 2004 16:12:28 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8NECS0M025636
	for <dal@ivoa.net>; Thu, 23 Sep 2004 16:12:28 +0200 (MEST)
Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8NECQSV025132
	for <dal@ivoa.net>; Thu, 23 Sep 2004 16:12:26 +0200 (CEST)
Received: (from womullan@localhost)
	by skysrv.pha.jhu.edu (8.11.6/8.11.6) id i8NECPA21102;
	Thu, 23 Sep 2004 10:12:25 -0400
Date: Thu, 23 Sep 2004 10:12:25 -0400
From: "Wil O'Mullane" <womullan@skysrv.pha.jhu.edu>
To: Doug Tody <dtody@nrao.edu>
Cc: dal@ivoa.net
Subject: Re: DAL discussions in Pune
Message-ID: <20040923101224.D6830@skysrv.pha.jhu.edu>
References: <Pine.LNX.4.44.0409222029300.1315-100000@lepus.tuc.noao.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.44.0409222029300.1315-100000@lepus.tuc.noao.edu>; from dtody@nrao.edu on Wed, Sep 22, 2004 at 08:30:49PM -0600
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.22.6
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Wil O'Mullane" <womullan@skysrv.pha.jhu.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Doug,
there is only one VOQL session.
The agenda is posted. The second topic is the virtual table topic 
which indeed relates to DAL. If we need further discussion we
should do that in DAL-2. Masatoshi and I had assumed that those from VOQL 
interested in the overlap with DAL would go to a DAL session with that topic on it. 
Likewise that DAL people would come to VOQL - we asked that they not overlap.

So it may be good to at least put a 15 min session on VOQL/DAL in the DAL2 
we could recap anything coming out of VOQL then.

wil
On Wed, Sep 22, 2004 at 08:30:49PM -0600, Doug Tody wrote:
> IVOA DAL Working Group
> Pune, India 27-29 Sept 2004
> 
> 
> Hi DAL Folks -
> 
> Here is a draft agenda for the DAL sessions in Pune.
> 
> 
> DAL-1  Monday, Sept 27  14:00 - 15:30
> 
>     SSA data model V0.9 update (J. McDowell)
> 	- Includes new data model serializations
>     SSA query (M. Dolensky)
> 	- Formatting the query response VOTable, which is based on
> 	  mapping elements of the SSA data model into VOTable
> 
> 
> DAL-2  Tuesday, Sept 28  11:00 - 12:30
> 
>     VOSpec tool demo (P. Osuna)
> 	- Includes issue of dealing with flux unit conversions in
> 	  the spectral data model
>     SIA extension (P. Fernique for F. Bonnarrel, P. Osuna, et. al.)
> 	- Metadata extension scheme for adding arbitrary dataset
> 	  metadata to the DAL query respone (not just for SIA)
>     Data Staging in SIA (D. Tody - if there is time)
> 	- We need to start looking at long-running data access operations
> 	  and how to manage batch processes in DAL interfaces using
> 	  asynchronous messaging, polling, data staging, and so forth.
> 
> 
> We could also discuss SkyNode and ADQL integration into DAL, however
> since the sessions don't overlap this might be better done in the VOQL
> session, which immediately follows DAL-1.
> 
> A related discussion of data characterization will take place in DM-1,
> immediately before DAL-1.  This is an essential element of both SSA and
> the next version of SIA.
> 
> 	- Doug

From owner-dal@eso.org  Thu Sep 23 16:39:50 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8NEdm0M029659
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 23 Sep 2004 16:39:48 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8NEdm88029658
	for dal-outgoing; Thu, 23 Sep 2004 16:39:48 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8NEdl0M029653
	for <dal@ivoa.net>; Thu, 23 Sep 2004 16:39:47 +0200 (MEST)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8NEdhSV026652
	for <dal@ivoa.net>; Thu, 23 Sep 2004 16:39:45 +0200 (CEST)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id i8NEdS9f030504;
	Thu, 23 Sep 2004 08:39:31 -0600
Date: Thu, 23 Sep 2004 08:39:27 -0600 (MDT)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: "Wil O'Mullane" <womullan@skysrv.pha.jhu.edu>
cc: dal@ivoa.net
Subject: Re: DAL discussions in Pune
In-Reply-To: <20040923101224.D6830@skysrv.pha.jhu.edu>
Message-ID: <Pine.LNX.4.44.0409230833080.14100-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c
	on virgo
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.22.6
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Wil -

Ok, lets plan on that.

	- Doug


On Thu, 23 Sep 2004, Wil O'Mullane wrote:

> Doug,
> there is only one VOQL session.
> The agenda is posted. The second topic is the virtual table topic 
> which indeed relates to DAL. If we need further discussion we
> should do that in DAL-2. Masatoshi and I had assumed that those from VOQL 
> interested in the overlap with DAL would go to a DAL session with that topic on it. 
> Likewise that DAL people would come to VOQL - we asked that they not overlap.
> 
> So it may be good to at least put a 15 min session on VOQL/DAL in the DAL2 
> we could recap anything coming out of VOQL then.
> 
> wil
> On Wed, Sep 22, 2004 at 08:30:49PM -0600, Doug Tody wrote:
> > IVOA DAL Working Group
> > Pune, India 27-29 Sept 2004
> > 
> > 
> > Hi DAL Folks -
> > 
> > Here is a draft agenda for the DAL sessions in Pune.
> > 
> > 
> > DAL-1  Monday, Sept 27  14:00 - 15:30
> > 
> >     SSA data model V0.9 update (J. McDowell)
> > 	- Includes new data model serializations
> >     SSA query (M. Dolensky)
> > 	- Formatting the query response VOTable, which is based on
> > 	  mapping elements of the SSA data model into VOTable
> > 
> > 
> > DAL-2  Tuesday, Sept 28  11:00 - 12:30
> > 
> >     VOSpec tool demo (P. Osuna)
> > 	- Includes issue of dealing with flux unit conversions in
> > 	  the spectral data model
> >     SIA extension (P. Fernique for F. Bonnarrel, P. Osuna, et. al.)
> > 	- Metadata extension scheme for adding arbitrary dataset
> > 	  metadata to the DAL query respone (not just for SIA)
> >     Data Staging in SIA (D. Tody - if there is time)
> > 	- We need to start looking at long-running data access operations
> > 	  and how to manage batch processes in DAL interfaces using
> > 	  asynchronous messaging, polling, data staging, and so forth.
> > 
> > 
> > We could also discuss SkyNode and ADQL integration into DAL, however
> > since the sessions don't overlap this might be better done in the VOQL
> > session, which immediately follows DAL-1.
> > 
> > A related discussion of data characterization will take place in DM-1,
> > immediately before DAL-1.  This is an essential element of both SSA and
> > the next version of SIA.
> > 
> > 	- Doug
> 
> 

From owner-dm@eso.org  Tue Sep 28 12:34:06 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8SAXI06019819
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 28 Sep 2004 12:33:18 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8SAXIhv019818
	for dm-outgoing; Tue, 28 Sep 2004 12:33:18 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8SAXI06019814;
	Tue, 28 Sep 2004 12:33:18 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8SAXGSV015747;
	Tue, 28 Sep 2004 12:33:16 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i8SAXGvY082632
          ; Tue, 28 Sep 2004 12:33:16 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id MAA11238;
	Tue, 28 Sep 2004 12:26:20 +0200 (MET DST)
Date: Tue, 28 Sep 2004 12:26:20 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200409281026.MAA11238@alinda.u-strasbg.fr>
To: amsr@jb.man.ac.uk, busko@stsci.edu
Subject: Re: Comments on Spectrum Data Model 0.9
Cc: dal@ivoa.net, dm@ivoa.net
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [130.79.200.1]); Tue, 28 Sep 2004 12:33:16 +0200 (CEST)
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.28.0
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Here are some comments on the Spectrum data model
I hope it'not too late, because this document has been 
presented in Pune allready, but the documents says 
remarks are due for October 1st!

I am not really competent in spectra, that's the reason why I give only
general purpose remarks, as a participant to DAL and DM working groups.
Detail remark:
    In section 5.5 Data Identification Model the table "Packaging Fields" should be
named "Data Identification fields". The Packaging section itself is described later
in the text.  The same misnaming occurs also in the xml schema at the end of the draft.

The main point I have about this draft is about the VOTable serialization.
Actually I think the proposed Serialization is not exactly adapted to an
SED with several segments (and therefore several data tables)
It is also not adapted to the metadata description of several SED, which
is actually something we need under SSA at the data discovery / data retrieval 
level (like in SIAP 1.0 and the proto SSA developped for the AVO 2nd demo).
The draft  proposal will work of course with an SED with one single segment, 
which may be the scope of the document.
The reason for that limitation is obviously coming from  mapping the model 
attributes/xml elements to PARAMS, and not to FIELDS in a (VO) TABLE.

   But if we think to generalize (page 22) a more general mapping from a model
(classes, associations, aggregations) or its xschema representations and 
VOTABLE, the basic assumption is that a class (an xml type/element) is a table.
Each lower level attribute/element of a class/element  is a VOTABLE FIELD
Each instance of a class (a complex element) can then be a row in the table.
aggregations are indeed well represented by groups of FIELDS
Links between rows in different tables (model associations or composition)
can be represented by using index columns and reference mechanisms
or by using the recurrent definition of the RESOURCE eelemnt in VOTABLE.
Using PARAMS can be seen as a specific implementation when dealing with
single objects.
The table SPECTRUM itself should have a less specific managment than in the draft
in that case. It is only one class among others.
Such a generalization could address some of the concerns made by Anita Richards
in her mail of  September 21st

   Mireille Louys and I wrote an IVOA note about principles to map a data model
in VOTABle (Document ID: ModelVOTSer-20040522). The reader can infer what can
happen if we start from the xshema representation instead of the UML one.
We used these principles for the IDHA format in the AVO and Aladin metadatrees.
Some of these rules are also underlying the proposal made by T.Boch,  P.fernique,
M.Louys, P.Osuna , J.Salgado and myself for SIA Extesnsions.

If the authors of the draft are interested I can send a slightly modified version of the
proposed VOTABLE serialisation, which I think is more general 

Regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dm@eso.org  Tue Sep 28 12:45:16 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8SAjC06021460
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 28 Sep 2004 12:45:12 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8SAjCqZ021459
	for dm-outgoing; Tue, 28 Sep 2004 12:45:12 +0200 (MEST)
Message-Id: <200409281045.i8SAjCqZ021459@mercury.hq.eso.org>
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Date: Tue, 28 Sep 2004 13:31:07 +0400 (MSD)
From: "Igor V. Chilingarian" <chil@sai.msu.su>
To: dal@ivoa.net, dm@ivoa.net
cc: prugniel@obs.univ-lyon1.fr
Subject: comments concerning SSA and spectral data model
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: "Igor V. Chilingarian" <chil@sai.msu.su>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


Hi all,

Today in Pune we had a short discussion with Jonathan McDowell
and Philipe Prugniel concerning SSA and spectral data model.

I'd like to post some notes as a result of our discussion.

1/
As far many spectra exist, especially in the optical band, represented as
1D-FITS images with a wavelength scale specified as a WCS and this way of
representation doesn't fit the spectral data model, we propose to include
to the metadata some optional keywords describing wavelength sampling in
several simple and widely-used cases in addition to the "wl-flux" table.

Actually, it is not trivial to recover the type of the wavelength sampling
from the individual points, because it is necessary to check different
possibilities: linear sampling, logarithmic sampling etc. So, we propose
to add parameters for
	1) wavelength sampling type: linear or logarithmical
	2) starting wavelength
	3) wavelength step
	4?) unit

The issue is a unit. It is supposed to be already contained in the
metadata, but i.e. for logarithmically rebinned spectra that are widely
used in the extragalactic studies, the wavelength and step are specified
in the logarithmic units that are not connected directly to Angstroms, but
more to km/s. This is a point TBD

Adding this keywords will allow to easyly use existing tools for spectral
data processing and analysis without major modifications.

2/
In the future, it would be nice to have a possibility to describe not only
the spectral resolution in each point of the spectrum (that is a case for
probably v.2), but also a shape of the line-spread function, because for
some studies related to kinematics and stellar population of galaxies this
is a crucial point. I rised this question on the DAL session yesterday.

With best regards,
						Igor

From owner-dal@eso.org  Wed Sep 29 07:21:23 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8T5LJjF018949
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 29 Sep 2004 07:21:19 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8T5LJuU018948
	for dal-outgoing; Wed, 29 Sep 2004 07:21:19 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8T5LIjF018944
	for <dal@ivoa.net>; Wed, 29 Sep 2004 07:21:18 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8T5LG0o001903
	for <dal@ivoa.net>; Wed, 29 Sep 2004 07:21:17 +0200 (CEST)
Received: from dropbox.aoc.nrao.edu (dropbox [146.88.1.13])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id i8T5LAc04608
	for <dal@ivoa.net>; Tue, 28 Sep 2004 23:21:10 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by dropbox.aoc.nrao.edu (8.12.8/8.12.8/smtp-gateway) with ESMTP id i8T5L95A012248;
	Tue, 28 Sep 2004 23:21:10 -0600
Date: Tue, 28 Sep 2004 23:21:09 -0600 (MDT)
From: Doug Tody <dtody@aoc.nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net
Subject: DAL WG presentations in Pune
Message-ID: <Pine.LNX.4.44.0409282318310.29404-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.4, required 7,
	BAYES_01 -5.40, USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.28.5
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@aoc.nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

To everyone who presented material in the DAL WG session in Pune,
please upload your presentations or other documents to the WG TWiki
page at:   http://www.ivoa.net/twiki/bin/view/IVOA/InterOpSep2004DAL

From owner-dal@eso.org  Wed Sep 29 10:25:01 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8T8NXZF007739
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 29 Sep 2004 10:23:33 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8T8NXiw007738
	for dal-outgoing; Wed, 29 Sep 2004 10:23:33 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8T8NOZF007727;
	Wed, 29 Sep 2004 10:23:24 +0200 (MEST)
Received: from eso.org (vpn-7.hq.eso.org [134.171.76.7])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i8T8NLI16529;
	Wed, 29 Sep 2004 10:23:22 +0200 (MEST)
Message-ID: <415A70F7.7080901@eso.org>
Date: Wed, 29 Sep 2004 10:23:19 +0200
From: Markus Dolensky <mdolensk@eso.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, de
MIME-Version: 1.0
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>, dal@ivoa.net
CC: busko@stsci.edu
Subject: Re: Comments on Spectrum Data Model 0.9
References: <200409281026.MAA11238@alinda.u-strasbg.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <mdolensk@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> The reason for that limitation is obviously coming from  mapping the model 
> attributes/xml elements to PARAMS, and not to FIELDS in a (VO) TABLE.

Nope.
PARAM elements are a shortcut for table columns which contain only a 
single distinct value in all cells. In practice all PARAM elements could 
become columns.

In the given example most attributes are given as PARAM elements rather 
than FIELDs, since otherwise it would be a very wide table, and 
therefore impracticle for a human reader of the document. In practice 
when a software client consumes the data this will be different, of course.

> If the authors of the draft are interested I can send a slightly modified version of the
> proposed VOTABLE serialisation, which I think is more general 

Surely yes.
There's a sample file on the Wiki which got updated a few days ago:
http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample1.xml

Cheers,
Markus

From owner-radiovo@eso.org  Thu Sep 30 12:56:30 2004
Return-Path: <owner-radiovo@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8UAuDQc004453
	for <radiovo-outgoing@mercury.hq.eso.org>; Thu, 30 Sep 2004 12:56:13 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8UAuDFL004452
	for radiovo-outgoing; Thu, 30 Sep 2004 12:56:13 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-radiovo@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8UAuAQc004446;
	Thu, 30 Sep 2004 12:56:10 +0200 (MEST)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8UAu80o018928;
	Thu, 30 Sep 2004 12:56:09 +0200 (CEST)
Received: from star1.jb.man.ac.uk ([130.88.24.176])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1CCybY-000NZf-C3; Thu, 30 Sep 2004 11:56:08 +0100
Received: from [130.88.24.146] (helo=megahard)
	by star1.jb.man.ac.uk with esmtp (Exim 3.03 #2)
	id 1CCybY-0006Gd-00; Thu, 30 Sep 2004 11:56:08 +0100
Date: Thu, 30 Sep 2004 11:56:06 +0100 (BST)
From: Anita Richards <amsr@jb.man.ac.uk>
X-X-Sender: amsr@megahard
To: dal@ivoa.net, radiovo@ivoa.net
Subject: SIAP and previews
Message-ID: <Pine.GSO.4.53.0409301139280.3893@megahard>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1CCybY-000NZf-C3*o47giUi/kpU*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.29.6
X-Virus-Scanned: by amavisd-new
Sender: owner-radiovo@eso.org
Precedence: bulk
Reply-To: Anita Richards <amsr@jb.man.ac.uk>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


SIAP v1.0 looks very suitable forradio data including 'virtual' images
which are created on demand from visibility data.  However in Section  3.
"Image Service Types" I am not sure how to indicate that more than one of
the subgroups 1-4 might be available from a single archive. At present 4.
Pointed Image Archive states that if the archive also contains surveys
that should be registered separately.  Does this cover the situation where
you have e.g. virtual images available for a collection of 10' fields of
view, and 10" ready made images for the centre of each field? There might
be other situations where e.g. low-res images of a large field are
ready-made but high-res cut-outs or mosaic tiles are extracted on demand.
The ready-made images would often be much quicker to access but less
suitable for science.  A third instance is the preview jpegs provided by
Aladin.

Is there a need for a category 5. Preview or is this covered by 4.? - will
users realise that they might also be able to look for customised images?

cheers
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO Astronomer
MERLIN/VLBI National Facility, University of Manchester,
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).

From owner-radiovo@eso.org  Thu Sep 30 16:14:35 2004
Return-Path: <owner-radiovo@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8UEESet001473
	for <radiovo-outgoing@mercury.hq.eso.org>; Thu, 30 Sep 2004 16:14:29 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i8UEESAS001472
	for radiovo-outgoing; Thu, 30 Sep 2004 16:14:28 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-radiovo@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8UEEHet001439;
	Thu, 30 Sep 2004 16:14:17 +0200 (MEST)
Received: from mail.ncsa.uiuc.edu (mail.ncsa.uiuc.edu [141.142.2.28])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i8UEEE0o029361;
	Thu, 30 Sep 2004 16:14:15 +0200 (CEST)
X-Envelope-From: rplante@poplar.ncsa.uiuc.edu
Received: from poplar.ncsa.uiuc.edu (poplar.ncsa.uiuc.edu [141.142.65.122])
	by mail.ncsa.uiuc.edu (8.11.7/8.11.7) with ESMTP id i8UEE6W17196;
	Thu, 30 Sep 2004 09:14:06 -0500
Received: from poplar.ncsa.uiuc.edu (localhost.localdomain [127.0.0.1])
	by poplar.ncsa.uiuc.edu (8.12.8/8.12.8) with ESMTP id i8UEE6Wh014176;
	Thu, 30 Sep 2004 09:14:06 -0500
Received: from localhost (rplante@localhost)
	by poplar.ncsa.uiuc.edu (8.12.8/8.12.8/Submit) with ESMTP id i8UEE6hi014172;
	Thu, 30 Sep 2004 09:14:06 -0500
Date: Thu, 30 Sep 2004 09:14:06 -0500 (CDT)
From: Ray Plante <rplante@ncsa.uiuc.edu>
To: dal@ivoa.net, <radiovo@ivoa.net>
Subject: Re: SIAP and previews
In-Reply-To: <Pine.GSO.4.53.0409301139280.3893@megahard>
Message-ID: <Pine.LNX.4.44.0409300851240.9866-100000@poplar.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-NCSA-MailScanner-Information: Please contact the help@ncsa.uiuc.edu for more information
X-NCSA-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.104326, Antispam-Data: 2004.9.29.6
X-Virus-Scanned: by amavisd-new
Sender: owner-radiovo@eso.org
Precedence: bulk
Reply-To: Ray Plante <rplante@ncsa.uiuc.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hey Anita,

On Thu, 30 Sep 2004, Anita Richards wrote:
> SIAP v1.0 looks very suitable forradio data including 'virtual' images
> which are created on demand from visibility data.  However in Section  3.
> "Image Service Types" I am not sure how to indicate that more than one of
> the subgroups 1-4 might be available from a single archive.  At present 4.
> Pointed Image Archive states that if the archive also contains surveys
> that should be registered separately.  Does this cover the situation where
> you have e.g. virtual images available for a collection of 10' fields of
> view, and 10" ready made images for the centre of each field? 

Each Image Service Type represents a different kind of behavior of the 
SIAP serivce.  If, hypothetically speaking, you had an implementation that 
qualified as being more that one service type, the service input interface 
does not allow the user to specify which behavior (e.g. cutout, 
mosaic--your generation of "virtual" images, static image retrieval).  In 
my mind this is not a bug, but rather a feature.  It allows the same query 
to be sent any SIAP service of any type.  Image generation paramters not 
supported by pointed archive types are ignored.  

Thus, in the SIA model, users that wish to select only certain behaviors
(e.g. cutout types), they filter via service selection with the registry.  
That is, if you want to support both on-the-fly creation of virtual images
(a Mosaic type) and a static image behavior (Atlas or Pointed), then you
register each as separate resources.  Of course, you can use a single
implementation for each one; just include an argument that selects the
image service type behavior in the registered base URL.

> Is there a need for a category 5. Preview or is this covered by 4.? - will
> users realise that they might also be able to look for customised images?

Previews are recognized by their FORMAT being labeled as a graphics image 
types (JPEG, PNG, GIF).  The FORMAT input allows one to select only 
previews.  Thus, I see this as an independent axis to the service type.  
As an example, some cutout services are able to create JPEG previews that 
are made "to order".  

cheers,
Ray

From owner-dal@eso.org  Wed Oct 20 16:32:40 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9KEW98Z023193
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 20 Oct 2004 16:32:10 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i9KEW9d9023192
	for dal-outgoing; Wed, 20 Oct 2004 16:32:09 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9KERq9n022086;
	Wed, 20 Oct 2004 16:31:55 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9KELq2i012604;
	Wed, 20 Oct 2004 16:21:53 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i9KELpMd072282
          ; Wed, 20 Oct 2004 16:21:51 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id QAA29766;
	Wed, 20 Oct 2004 16:14:34 +0200 (MET DST)
Date: Wed, 20 Oct 2004 16:14:34 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200410201414.QAA29766@alinda.u-strasbg.fr>
To: dal@ivoa.net, mdolensk@eso.org
Subject: Re: Comments on Spectrum Data Model 0.9
Cc: busko@stsci.edu
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [130.79.200.1]); Wed, 20 Oct 2004 16:21:52 +0200 (CEST)
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.20.0
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

 Dear Marcus, dear dal-people,
In answer to your mail of Sept the 29th

<> The reason for that limitation is obviously coming from  mapping the model 
<> attributes/xml elements to PARAMS, and not to FIELDS in a (VO) TABLE.
<
<Nope.
<PARAM elements are a shortcut for table columns which contain only a 
<single distinct value in all cells. In practice all PARAM elements could 
<become columns.
<
<In the given example most attributes are given as PARAM elements rather 
<than FIELDs, since otherwise it would be a very wide table, and 
<therefore impracticle for a human reader of the document. In practice 
<when a software client consumes the data this will be different, of course.

Now That I had the opportunity to discuss orally with you last week:
(and also with Pedro Osuna)
I must say that I understand better where we differ. 
The VOTABLE serialization you were proposing is intended , lets'say
for the RETRIEVAL method of SSA and not for the QUERY response.

I always believed  that the Query response could also be based on
the data model and some Data Model --> VOTABLE translation rules.
It is because I had the SSA Query reponse in mind that I thought 
that most of the PARAMS should be allowed to become FIELDS
If I understand well my recent discussions with Doug (by email),
I think this also our roadmap for SIA1.1: How do we go from
ivoa:OBservation/characterization data model to a Votable Image
Query Response is a large part of it.
And I consider that although separeted as two different tasks for
the DAL working group, SIA and SSA should not diverge too much.
Currently a draft for some mechanisms of Extensions in SIA is
circulating between Osuna/Salgado, CDS and Doug. 
It will be published on the list as soon as possible, but
I understood it was  urgent to react on SSA now, although
It would have been better for clarity to present the adaptations 
I am proposing in the files referenced here AFTER publication
of the draft.


<
<> If the authors of the draft are interested I can send a slightly modified version of the
<> proposed VOTABLE serialisation, which I think is more general 
<
<Surely yes.
<There's a sample file on the Wiki which got updated a few days ago:
<http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample1.xml
<
<Cheers,
<Markus
<

I took your example file and adapted it to produce four different
files.
 The two basic ideas are:
    - a) Associations , or one to n relationships in the model are 
translated by either an index/key mechanism using the "ref" Feature
of VOTAble (3 first files), or recursive inclusion of VOTABLE RESOURCES. 
GROUPS are better for aggregation (or one to one relationships)
    - b) Forcing some Organisation of the response VOTABLE helps the 
client software to define immediatly appropriate data structures based 
on the model with appropriate relationships, while keeping the simplicity 
of VOTABLE parsing. 
It allows also some normalisation and avoid redondancy.
It can eventually allow a simple software to use a main table and to
ignore details hidden in extensions.

    1 ) The first file is a possible query response (without "Access 
reference field)
(http://alinda.u-strasbg.fr/SSA/ssaquery1.xml)
based on the Spectrum data model, closer as possible to your example
(http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample1.xml)  where the main 
table is containing the descriptions of the (SED / Target)s metadata, and
where individual segments are placed in an extension table indexed
by the "Target Name" field.  

    2) The second file http://alinda.u-strasbg.fr/SSA/ssaquery2.xml)
is taking into account the debate about what should be in the
main section of the query response, by letting in the main table the 
individual segment metadata.
     Details on the general SED/Target common to (several of) them are  
in an Extension Table, indexed again by the "Target Name".


   3) The third file shows how the mechanism proposed can be extended
up to the retrieval of several full spectra. 
     http://alinda.u-strasbg.fr/SSA/ssample2.xml
    is just the same as 
      http://alinda.u-strasbg.fr/SSA/ssaquery1.xml
     with a "Point" section, where each individual Data table is hooked
to the appropriate segment metadata using the "DataSet ID" FIELD.

   4) the fourth file http://alinda.u-strasbg.fr/SSA/ssample3.xml
is an alternative to the third one using the recursive inclusion of
RESOURCES instead of indexing mechanisms.

I added a few commentary sections in the files to help the 
reader to see the changes. The general SED sections and general
segment metadata are all considered as FIELDS instead of PARAMS
in order to avoid repetitions of PARAM definitions and attributes.    

In conclusion, I think the document should not say that the
VOTABLE serialization it proposes is the unique way to 
serialize a data model, (the document serialization  is more adapted to 
the Retrieval case actually) and should let open other 
serializations more adapated to the Query Response case .

Best Regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Wed Oct 20 17:34:40 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9KFYMDZ002421
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 20 Oct 2004 17:34:22 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i9KFYMhd002420
	for dal-outgoing; Wed, 20 Oct 2004 17:34:22 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9KFYFDZ002405
	for <dal@ivoa.net>; Wed, 20 Oct 2004 17:34:16 +0200 (MEST)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9KEgPG6008826
	for <dal@ivoa.net>; Wed, 20 Oct 2004 16:42:25 +0200 (CEST)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id i9KEgPMd079824
          for <dal@ivoa.net>; Wed, 20 Oct 2004 16:42:25 +0200 (CEST)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id QAA29845
	for dal@ivoa.net; Wed, 20 Oct 2004 16:35:08 +0200 (MET DST)
Date: Wed, 20 Oct 2004 16:35:08 +0200 (MET DST)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200410201435.QAA29845@alinda.u-strasbg.fr>
To: dal@ivoa.net
Subject: Small Detail in Spectrum Data Model
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [130.79.200.1]); Wed, 20 Oct 2004 16:42:25 +0200 (CEST)
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.20.0
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


I think it would be good to give a "Type" for each segment
I mean: is this segment a Photmetry Point, a Spectrum, a time sery , etc ...
probably it can be an attribute in the Data Identification Class.


Regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Thu Oct 21 15:51:36 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9LDp9GE008088
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 21 Oct 2004 15:51:09 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id i9LDp94M008087
	for dal-outgoing; Thu, 21 Oct 2004 15:51:09 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from serapis.hq.eso.org (serapis.hq.eso.org [134.171.7.10])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id i9LDp5GE008077
	for <dal@ivoa.net>; Thu, 21 Oct 2004 15:51:05 +0200 (MEST)
Received: from eso.org (pc003499.hq.eso.org [134.171.40.117])
	by serapis.hq.eso.org (8.11.7+Sun/8.11.7) with ESMTP id i9LDp5D05779
	for <dal@ivoa.net>; Thu, 21 Oct 2004 15:51:05 +0200 (MEST)
Message-ID: <4177BEBE.5050703@eso.org>
Date: Thu, 21 Oct 2004 15:50:54 +0200
From: Markus Dolensky <Markus.Dolensky@eso.org>
Organization: European Southern Observatory
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en, de-AT
MIME-Version: 1.0
To: IVOA Data Access Layer <dal@ivoa.net>
Subject: Re: Small Detail in Spectrum Data Model
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Markus Dolensky <Markus.Dolensky@eso.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi,

Francois Bonnarel wrote:
> I think it would be good to give a "Type" for each segment
> I mean: is this segment a Photmetry Point, a Spectrum, a time sery , etc ...
> probably it can be an attribute in the Data Identification Class.

This was a bug in my sample which specified only a single global "SegmentType".
Now there is a SegmentType for each Segment. Now it should be compliant with
the SSA DM doc. http://hea-www.harvard.edu/~jcm/vo/docs/spec.html#s56

The relevant code snippet
http://www.ivoa.net/internal/IVOA/IvoaDAL/ssample20041021.xml

<PARAM name="Segment Type" datatype="char" arraysize="*"
utype="sed:SED.SegmentType" ucd="meta.code" value="Photometry">
   <VALUES>
     <OPTION value="Photometry"/>
     <OPTION value="TimeSeries"/>
     <OPTION value="Spectrum"/>
   </VALUES>
</PARAM>

Thanks for pointing this out,
Markus




-- 
+---
| Markus Dolensky   Mailto:Markus.Dolensky@eso.org
| AVO Technical Lead          Web: www.euro-vo.org
| Voice: ++49 89 32006/261  Fax: ++49 89 32006/480
+---

From owner-dm@eso.org  Wed Nov 17 17:48:15 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAHGluhb008123
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 17 Nov 2004 17:47:56 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAHGlutq008122
	for dm-outgoing; Wed, 17 Nov 2004 17:47:56 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAHGlrhb008104;
	Wed, 17 Nov 2004 17:47:53 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAHGln2i000914;
	Wed, 17 Nov 2004 17:47:49 +0100 (CET)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id iAHGlmDb013157;
	Wed, 17 Nov 2004 11:47:48 -0500 (EST)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id iAHGllnW015335;
	Wed, 17 Nov 2004 11:47:47 -0500 (EST)
Date: Wed, 17 Nov 2004 11:47:47 -0500 (EST)
Message-Id: <200411171647.iAHGllnW015335@urania.cfa.harvard.edu>
To: dal@ivoa.net, dm@ivoa.net
Subject: SED data model v0.92
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.16.8
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


A group led by myself and Doug Tody have been working on
the data model and data formats for the Simple Spectral Access Protocol,
which represents 1D spectra, time series and spectral energy distributions.
The document is still at a draft stage but has now reached a level
of maturity that it may be interesting for people to look at.
You can find it at
 http://hea-www.harvard.edu/~jcm/vo/docs/spec.html
and I'll put it on the twiki in the next few days.
   Jonathan

From owner-dal@eso.org  Thu Nov 18 15:29:47 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAIETF0f009551
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 18 Nov 2004 15:29:16 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAIETFct009550
	for dal-outgoing; Thu, 18 Nov 2004 15:29:15 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAIET80f009532;
	Thu, 18 Nov 2004 15:29:08 +0100 (MET)
Received: from earth.astro.umd.edu (earth.astro.umd.edu [129.2.14.2])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAIET62i008229;
	Thu, 18 Nov 2004 15:29:06 +0100 (CET)
Received: from [129.2.15.121] (lap40.astro.umd.edu [129.2.15.121])
	by earth.astro.umd.edu (Postfix) with ESMTP
	id 882EA2C426; Thu, 18 Nov 2004 09:29:01 -0500 (EST)
Message-ID: <419CB1AB.5040004@gsfc.nasa.gov>
Date: Thu, 18 Nov 2004 09:28:59 -0500
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411171647.iAHGllnW015335@urania.cfa.harvard.edu>
In-Reply-To: <200411171647.iAHGllnW015335@urania.cfa.harvard.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.18.0
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Jonathan,
    I am just beginning to look at theSED document.  I do not see where 
one can place an error on each individual point.  Have I missed it?   
This would be needed if there is a complex procedure by which the SED is 
produced (say dozens of  partially overlapping spectra are combined to 
produce a grand SED) and one does not wish to reproduce the procedure to 
get an error bar on a particular point.  In fact, one can easily imagine 
that SEDs will often be exactly this, cause otherwise one may be better 
off with a simpler set of spectra.

Secondly, you have for upper limit information:

"If the data provider has only upper limit information, it should be 
represented by setting the flux value and the lower error value equal to 
the limit. "

But what about the postiiveError limit?  Is it then set to zero?
Also, the lower error value should be called the negativeError value 
since it can be lower or  greater  than the positiveError limit.

Finally, for now, I think redshiftError and redshiftConfidence should be 
children of redshift (in the XML Schema), as all good quantities should.

Ed



Jonathan McDowell wrote:

>A group led by myself and Doug Tody have been working on
>the data model and data formats for the Simple Spectral Access Protocol,
>which represents 1D spectra, time series and spectral energy distributions.
>The document is still at a draft stage but has now reached a level
>of maturity that it may be interesting for people to look at.
>You can find it at
> http://hea-www.harvard.edu/~jcm/vo/docs/spec.html
>and I'll put it on the twiki in the next few days.
>   Jonathan
>
>  
>

From owner-dal@eso.org  Fri Nov 19 07:17:02 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJ6GSHf001985
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 19 Nov 2004 07:16:28 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAJ6GRxm001984
	for dal-outgoing; Fri, 19 Nov 2004 07:16:28 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJ6GLHf001972;
	Fri, 19 Nov 2004 07:16:21 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJ6GJ2i020679;
	Fri, 19 Nov 2004 07:16:19 +0100 (CET)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id iAJ6GHDb019176;
	Fri, 19 Nov 2004 01:16:17 -0500 (EST)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id iAJ6GHDc017428;
	Fri, 19 Nov 2004 01:16:17 -0500 (EST)
Date: Fri, 19 Nov 2004 01:16:17 -0500 (EST)
Message-Id: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu>
To: dal@ivoa.net, dm@ivoa.net, edward.j.shaya.1@gsfc.nasa.gov
Subject: Re: SED data model v0.92
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.18.33
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Hi Ed,

> Jonathan,
>     I am just beginning to look at theSED document.  I do not see where 
> one can place an error on each individual point.  Have I missed it?   

Yes. 
The Flux object has an accuracy, and there's one for each Point.
This should be clear in the diagram and in the serialization examples,
but it isn't clear in the text in section 4.7. Sorry about that.

> 
> Secondly, you have for upper limit information:
> 
> "If the data provider has only upper limit information, it should be 
> represented by setting the flux value and the lower error value equal to 
> the limit. "
> 
> But what about the postiiveError limit?  Is it then set to zero?

Yes, I'll add such text.
This is one point I'd particularly encourage feedback on - is this
an OK way to go for upper limits? I don't want to add an extra field
that's usually not used.

> Finally, for now, I think redshiftError and redshiftConfidence should be 
> children of redshift (in the XML Schema), as all good quantities should.

Agreed.
 Jonathan

From owner-dal@eso.org  Fri Nov 19 09:22:07 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJ8LqHf012241
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 19 Nov 2004 09:21:53 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAJ8Lq6O012240
	for dal-outgoing; Fri, 19 Nov 2004 09:21:52 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJ8LjHf012207;
	Fri, 19 Nov 2004 09:21:45 +0100 (MET)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJ8Lh2i023378;
	Fri, 19 Nov 2004 09:21:44 +0100 (CET)
Received: from axp0.ast.man.ac.uk ([130.88.9.45])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1CV41X-0006PW-Ab; Fri, 19 Nov 2004 08:21:43 +0000
Received: from dsb (helo=localhost)
	by axp0.ast.man.ac.uk with local-esmtp (Exim 2.12 #1)
	id 1CV41W-00089p-00; Fri, 19 Nov 2004 08:21:42 +0000
Date: Fri, 19 Nov 2004 08:21:42 +0000 (GMT)
From: David Berry <dsb@ast.man.ac.uk>
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
In-Reply-To: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu>
Message-ID: <Pine.OSF.4.53.0411190817330.15228@axp0.ast.man.ac.uk>
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1CV41X-0006PW-Ab*UmX/Jmm9Jg2*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.18.39
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: David Berry <dsb@ast.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Jonathan,
         Am I correcting in thinking that if the spectral coordinate
is linear with channel number, you still have to supply all the spectral
coordinate values explicitly, rather than just giving a scale and offset?

David

From owner-dm@eso.org  Fri Nov 19 15:48:41 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJEmNHf002680
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 19 Nov 2004 15:48:23 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAJEmNPB002679
	for dm-outgoing; Fri, 19 Nov 2004 15:48:23 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJEmJHf002671;
	Fri, 19 Nov 2004 15:48:19 +0100 (MET)
Received: from earth.astro.umd.edu (earth.astro.umd.edu [129.2.14.2])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJEmHRQ004849;
	Fri, 19 Nov 2004 15:48:17 +0100 (CET)
Received: from [129.2.15.121] (lap40.astro.umd.edu [129.2.15.121])
	by earth.astro.umd.edu (Postfix) with ESMTP
	id 6CF8E2C48F; Fri, 19 Nov 2004 09:48:16 -0500 (EST)
Message-ID: <419E07AF.1060903@gsfc.nasa.gov>
Date: Fri, 19 Nov 2004 09:48:15 -0500
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu>
In-Reply-To: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.18.39
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


>Yes. 
>The Flux object has an accuracy, and there's one for each Point.
>This should be clear in the diagram and in the serialization examples,
>but it isn't clear in the text in section 4.7. Sorry about that.
>
>  
>
I also do not see it in the XML Schema.

>>Secondly, you have for upper limit information:
>>
>>"If the data provider has only upper limit information, it should be 
>>represented by setting the flux value and the lower error value equal to 
>>the limit. "
>>
>>But what about the postiiveError limit?  Is it then set to zero?
>>    
>>
>
>Yes, I'll add such text.
>This is one point I'd particularly encourage feedback on - is this
>an OK way to go for upper limits? I don't want to add an extra field
>that's usually not used.
>
>  
>
Hopefully, it is rare that one only has upper limit info.  The observers 
certainly should provide the measured value even if it is below the 
noise.  There is non-zero information in that value.

Ed

From owner-dal@eso.org  Fri Nov 19 18:55:15 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJHsrHf022968
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 19 Nov 2004 18:54:53 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAJHsrGe022967
	for dal-outgoing; Fri, 19 Nov 2004 18:54:53 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJHsnHf022962;
	Fri, 19 Nov 2004 18:54:49 +0100 (MET)
Received: from amazone.ujf-grenoble.fr (amazone.ujf-grenoble.fr [193.54.238.254])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJHsl2i016798;
	Fri, 19 Nov 2004 18:54:48 +0100 (CET)
Received: from tibre1.ujf-grenoble.fr (tana1.ujf-grenoble.fr [152.77.18.74])
	by amazone.ujf-grenoble.fr (Switch-3.1.3/Switch-3.1.0/Configured  by JE 9 8 2004) with ESMTP id iAJHsZjA006352;
	Fri, 19 Nov 2004 18:54:35 +0100 (CET)
Received: from gagax1.obs.ujf-grenoble.fr (gagax1.obs.ujf-grenoble.fr [195.220.79.11])
	by tibre1.ujf-grenoble.fr (8.12.8p1/8.12.8) with ESMTP id iAJHsi2N053328;
	Fri, 19 Nov 2004 18:54:44 +0100 (CET)
	(envelope-from Gilles.Duvert@obs.ujf-grenoble.fr)
Received: from [193.54.238.142] (jmmc1.ujf-grenoble.fr [193.54.238.142])
	by gagax1.obs.ujf-grenoble.fr (AIX4.3/UCB 8.8.8/8.8.5) with ESMTP id SAA32158;
	Fri, 19 Nov 2004 18:54:34 +0100
Message-ID: <419E335A.3000602@obs.ujf-grenoble.fr>
Date: Fri, 19 Nov 2004 18:54:34 +0100
From: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>,
        Jonathan McDowell <jcm@head.cfa.harvard.edu>
CC: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov>
In-Reply-To: <419E07AF.1060903@gsfc.nasa.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.18.39
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Congratulations for the IVOA SED Data Model , this is an impressive 
piece of work.

If I may risk three comments, two on the draft itself, the other on 
comments of comments...
Sorry for the rather direct style, and for my probable misunderstanding 
of some parts of the document...

1) Ed Shaya wrote:

> Hopefully, it is rare that one only has upper limit info.  The 
> observers certainly should provide the measured value even if it is 
> below the noise.  There is non-zero information in that value.

Well, although having only upper limits may seem pitiful, a number of 
sound scientific results have been drawn in the past from 
undetectablilty results. Upper limits are really a result for SEDs, and 
used as such by astronomers. Since they are used, they are published and 
they will go  in the  VO...
 I just wanted to comment that a value *measured* cannot be *below* the 
noise. Only the noise level is meaningfull in this case (the text notes, 
and this is customary indeed, that authors usually "choose to render 
measurements as upper limits if the flux value is less than some 
multiple (e.g. 3) of the lower error" (note: shouldn't  be *Upper* 
error? ) ). The risk would be, if any *measured* value is set, that is 
is taken at face value, when only the noise level has sense. Could you 
use some kind of blanking value for the measured value in this? (or is 
there a general concept of upper limit that would go in the 
Quantity::Accuracy data model?)

2) in http://hea-www.harvard.edu/~jcm/vo/docs/spec.html, Errors are 
OPTIONAL?? Errors are part of any measurement, and should be enforced by 
the data model. Or is there provision for a sort of common error for all 
measurements? Because a measurement without errorbars should simply not 
exist  (but the reverse may exist, see above)!

3) http://hea-www.harvard.edu/~jcm/vo/docs/spec.html use  non standard  
old 'ergs'  (cgs) units... All documents produced in the 21st Century 
should promote MKSA units, and conversion to the dear cgs units of our 
grandfathers should be implicit and computer-assisted... ;^)

Best,

Gilles

-- 
----------------------------------------------------------------------------
Gilles DUVERT, Astronome        | Gilles.Duvert@obs.ujf-grenoble.fr
Laboratoire d'Astrophysique     | Phone: +33 (0)4 76.51.48.85
Observatoire de Grenoble        | Fax:   +33 (0)4.76.44.88.21
BP 53X  F-38041 GRENOBLE CEDEX  | LAOG (http://www-laog.obs.ujf-grenoble.fr)
Dir. Technique JMMC(http://mariotti.ujf-grenoble.fr) Resp. Informatique LAOG
----------------------------------------------------------------------------



From owner-dm@eso.org  Fri Nov 19 20:16:50 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJJGFHf029230
	for <dm-outgoing@mercury.hq.eso.org>; Fri, 19 Nov 2004 20:16:15 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAJJGF7V029229
	for dm-outgoing; Fri, 19 Nov 2004 20:16:15 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJJGBHf029223;
	Fri, 19 Nov 2004 20:16:11 +0100 (MET)
Received: from earth.astro.umd.edu (earth.astro.umd.edu [129.2.14.2])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAJJG9RQ014828;
	Fri, 19 Nov 2004 20:16:10 +0100 (CET)
Received: from [129.2.15.121] (lap40.astro.umd.edu [129.2.15.121])
	by earth.astro.umd.edu (Postfix) with ESMTP
	id 185D02C526; Fri, 19 Nov 2004 14:16:08 -0500 (EST)
Message-ID: <419E4671.9060606@gsfc.nasa.gov>
Date: Fri, 19 Nov 2004 14:16:01 -0500
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
Cc: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov> <419E335A.3000602@obs.ujf-grenoble.fr>
In-Reply-To: <419E335A.3000602@obs.ujf-grenoble.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.18.39
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


> 1) Ed Shaya wrote:
>
>> Hopefully, it is rare that one only has upper limit info.  The 
>> observers certainly should provide the measured value even if it is 
>> below the noise.  There is non-zero information in that value.
>
>
> Well, although having only upper limits may seem pitiful, a number of 
> sound scientific results have been drawn in the past from 
> undetectablilty results. Upper limits are really a result for SEDs, 
> and used as such by astronomers. Since they are used, they are 
> published and they will go  in the  VO...

Let me rephrase my first sentence:
Hopefully, it is rare that one only has the upper lmit  but no info on 
the actual readout or measured value of the upper limit point.
So, we agree that upper limits are important scientifically. 

> I just wanted to comment that a value *measured* cannot be *below* the 
> noise. Only the noise level is meaningfull in this case

No!  Even a negative measurement on a property that is non-negative is 
scientifically meaningful.  See below.

> (the text notes, and this is customary indeed, that authors usually 
> "choose to render measurements as upper limits if the flux value is 
> less than some multiple (e.g. 3) of the lower error" (note: shouldn't  
> be *Upper* error? ) ). 

You want the lower error bar to reach from the upper limit to the x-axis.

> The risk would be, if any *measured* value is set, that is is taken at 
> face value, when only the noise level has sense. Could you use some 
> kind of blanking value for the measured value in this? (or is there a 
> general concept of upper limit that would go in the Quantity::Accuracy 
> data model?)
>
All I need say here is that if 4 independent experiments come up  with  
0.9 sigma  detections of  some measurement that it would be awful  if 
they each  published  only the upper limits of the value.
The possibility that some moron may not look at the quoted noise levels 
before coming to some silly conclusion on a measurment does not 
compensate for missing out on  potentially important real discoveries 
that properly archived data makes possible.

>
>
> 3) http://hea-www.harvard.edu/~jcm/vo/docs/spec.html use  non 
> standard  old 'ergs'  (cgs) units... All documents produced in the 
> 21st Century should promote MKSA units, and conversion to the dear cgs 
> units of our grandfathers should be implicit and computer-assisted... ;^)
>
> Best,
>
> Gilles
>

From owner-dal@eso.org  Thu Nov 18 20:11:16 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAIJAg0f004307
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 18 Nov 2004 20:10:42 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAIJAflQ004306
	for dal-outgoing; Thu, 18 Nov 2004 20:10:41 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAIJAb0f004295
	for <dal@ivoa.net>; Thu, 18 Nov 2004 20:10:37 +0100 (MET)
Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAIJAY2i028714
	for <dal@ivoa.net>; Thu, 18 Nov 2004 20:10:35 +0100 (CET)
Received: (from sla@localhost)
	by geneva.ucolick.org (8.11.6/8.11.2) id iAIJAYq16898
	for dal@ivoa.net; Thu, 18 Nov 2004 11:10:34 -0800
Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183])
	by santo.ucolick.org (8.11.7p1+Sun/8.11.7) with ESMTP id iAIJ6rB07195
	for <sla@ucolick.org>; Thu, 18 Nov 2004 11:06:53 -0800 (PST)
Received: (from sla@localhost)
	by geneva.ucolick.org (8.11.6/8.11.2) id iAIJ6IH16843;
	Thu, 18 Nov 2004 11:06:18 -0800
Date: Thu, 18 Nov 2004 11:06:18 -0800
From: Steve Allen <sla@ucolick.org>
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Cc: Steve Allen <sla@ucolick.org>
Subject: Re: [fitswcs] [Fwd: SED data model v0.92]
Message-ID: <20041118190618.GA16639@ucolick.org>
References: <419CDA5E.7060802@nasa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <419CDA5E.7060802@nasa.gov>
User-Agent: Mutt/1.4.2.1i
X-Virus: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.18.0
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Steve Allen <sla@ucolick.org>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Greetings Jonathan,

On Thu 2004-11-18T12:22:38 -0500, William Pence hath forwarded:
> -------- Original Message --------
> Subject: SED data model v0.92
> Date: Wed, 17 Nov 2004 11:47:47 -0500 (EST)
> From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
> Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>

> A group led by myself and Doug Tody have been working on
> the data model and data formats for the Simple Spectral Access Protocol,
> which represents 1D spectra, time series and spectral energy distributions.
> The document is still at a draft stage but has now reached a level
> of maturity that it may be interesting for people to look at.
> You can find it at
>  http://hea-www.harvard.edu/~jcm/vo/docs/spec.html
> and I'll put it on the twiki in the next few days.
>    Jonathan


I have an immediate comment about section 4.5

    The reference time should be specified by a date in ISO-8601
    format.  The default value of the reference time is
    -4713-11-24T11:59:27.81, corresponding to the origin of Julian Day
    Number on the TT (Terrestrial Time) timescale.  Using TT is
    preferable to UTC because it does not contain leap seconds, so the
    elapsed time in days is just equal to the difference in JD values.

Can you justify the use of ISO 8601 for dates prior to the existence
of the Gregorian Calendar?

Does the ISO 8601 standard explicitly admit that negative values for
the year are acceptable?

The phrasing of the first sentence is still ambiguous.
The reference time should have its timescale immediately adjacent to
its value.
I believe that you are trying to say that the origin epoch is
JD=0.0 (TT)
which corresponds to (assuming negative ISO year is acceptable)
-4713-11-24T11:59:27.81 (pTAI)
where by "pTAI" I mean some sort of proleptic TAI.

The concept of a proleptic TAI, however, is very problematic
given the change in rate of TAI by 1 part in 1.e12 in 1977.
Over the elapsed span of years since the origin of JD that
rate difference amounts to nearly a full second.  As such the
current TT - TAI difference of 32.184 seconds would not result in
a TAI of 11:59:27.81 so long ago.

I suggest that you make it explicit that the default reference origin
is JD = 0.0 (TT).  If you give the corresponding calendar date
you must first verify that ISO permits negative years.  If that is not so
it is far safer to express it as Julian proleptic date=-4713 January 0.5 (TT).

And this is to say nothing of the value of Universal Time that
corresponds to JD=0.0 (TT), because that date is several thousand
years prior to the earliest eclipse records found by Stephenson and
Morrison for determining earth rotation.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla@ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93

From owner-dm@eso.org  Sat Nov 20 10:40:17 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAK9e2UL016157
	for <dm-outgoing@mercury.hq.eso.org>; Sat, 20 Nov 2004 10:40:02 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAK9e2VD016156
	for dm-outgoing; Sat, 20 Nov 2004 10:40:02 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Message-Id: <200411191821.iAJILjU1007589@head.cfa.harvard.edu>
To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
cc: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>,
        Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net,
        dm@ivoa.net
Subject: Re: SED data model v0.92 
In-reply-to: Your message of "Fri, 19 Nov 2004 18:54:34 +0100."
             <419E335A.3000602@obs.ujf-grenoble.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Nov 2004 13:21:45 -0500
From: Pepi Fabbiano <pepi@head.cfa.harvard.edu>
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Pepi Fabbiano <pepi@head.cfa.harvard.edu>
X-Virus-Scanned: by amavisd-new
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

> 1) Ed Shaya wrote:
> 
> > Hopefully, it is rare that one only has upper limit info.  The 
> > observers certainly should provide the measured value even if it is 
> > below the noise.  There is non-zero information in that value.
> 
> Well, although having only upper limits may seem pitiful, a number of 
> sound scientific results have been drawn in the past from 
> undetectablilty results. Upper limits are really a result for SEDs, and 
> used as such by astronomers. Since they are used, they are published and 
> they will go  in the  VO...
>  I just wanted to comment that a value *measured* cannot be *below* the 
> noise. Only the noise level is meaningfull in this case (the text notes, 
> and this is customary indeed, that authors usually "choose to render 
> measurements as upper limits if the flux value is less than some 
> multiple (e.g. 3) of the lower error" (note: shouldn't  be *Upper* 
> error? ) ). The risk would be, if any *measured* value is set, that is 
> is taken at face value, when only the noise level has sense. Could you 
> use some kind of blanking value for the measured value in this? (or is 
> there a general concept of upper limit that would go in the 
> Quantity::Accuracy data model?)

As someone who has written many papers using both detections and a significant 
number of upper limits, I entirely agree with the above comment.
 
> 2) in http://hea-www.harvard.edu/~jcm/vo/docs/spec.html, Errors are 
> OPTIONAL?? Errors are part of any measurement, and should be enforced by 
> the data model. Or is there provision for a sort of common error for all 
> measurements? Because a measurement without errorbars should simply not 
> exist  (but the reverse may exist, see above)!
> 

true 

> 3) http://hea-www.harvard.edu/~jcm/vo/docs/spec.html use  non standard  
> old 'ergs'  (cgs) units... All documents produced in the 21st Century 
> should promote MKSA units, and conversion to the dear cgs units of our 
> grandfathers should be implicit and computer-assisted... ;^)
>

I like cgs....
 
> Best,
> 
> Gilles

Cheers. -pepi


> ----------------------------------------------------------------------------
> Gilles DUVERT, Astronome        | Gilles.Duvert@obs.ujf-grenoble.fr
> Laboratoire d'Astrophysique     | Phone: +33 (0)4 76.51.48.85
> Observatoire de Grenoble        | Fax:   +33 (0)4.76.44.88.21
> BP 53X  F-38041 GRENOBLE CEDEX  | LAOG (http://www-laog.obs.ujf-grenoble.fr)
> Dir. Technique JMMC(http://mariotti.ujf-grenoble.fr) Resp. Informatique LAOG
> ----------------------------------------------------------------------------
> 
>

From owner-dal@eso.org  Mon Nov 22 16:39:51 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMFdRTj016060
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 22 Nov 2004 16:39:27 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAMFdRrE016059
	for dal-outgoing; Mon, 22 Nov 2004 16:39:27 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMFdLTj016037;
	Mon, 22 Nov 2004 16:39:21 +0100 (MET)
Received: from amazone.ujf-grenoble.fr (amazone.ujf-grenoble.fr [193.54.238.254])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMFdJ2i014486;
	Mon, 22 Nov 2004 16:39:19 +0100 (CET)
Received: from tibre2.ujf-grenoble.fr (tana2.ujf-grenoble.fr [152.77.24.22])
	by amazone.ujf-grenoble.fr (Switch-3.1.3/Switch-3.1.0/Configured  by JE 9 8 2004) with ESMTP id iAMFd092018048;
	Mon, 22 Nov 2004 16:39:01 +0100 (CET)
Received: from gagax1.obs.ujf-grenoble.fr (gagax1.obs.ujf-grenoble.fr [195.220.79.11])
	by tibre2.ujf-grenoble.fr (8.12.8p1/8.12.8) with ESMTP id iAMFd0WS002558;
	Mon, 22 Nov 2004 16:39:00 +0100 (CET)
	(envelope-from Gilles.Duvert@obs.ujf-grenoble.fr)
Received: from [193.54.238.142] (jmmc1.ujf-grenoble.fr [193.54.238.142])
	by gagax1.obs.ujf-grenoble.fr (AIX4.3/UCB 8.8.8/8.8.5) with ESMTP id QAA107978;
	Mon, 22 Nov 2004 16:38:59 +0100
Message-ID: <41A20813.5030902@obs.ujf-grenoble.fr>
Date: Mon, 22 Nov 2004 16:38:59 +0100
From: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
CC: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov> <419E335A.3000602@obs.ujf-grenoble.fr> <419E4671.9060606@gsfc.nasa.gov>
In-Reply-To: <419E4671.9060606@gsfc.nasa.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.21.12
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000



Ed Shaya wrote:

>
>> 1) Ed Shaya wrote:
>>
>>> Hopefully, it is rare that one only has upper limit info.  The 
>>> observers certainly should provide the measured value even if it is 
>>> below the noise.  There is non-zero information in that value.
>>
>>
>>
>> Well, although having only upper limits may seem pitiful, a number of 
>> sound scientific results have been drawn in the past from 
>> undetectablilty results. Upper limits are really a result for SEDs, 
>> and used as such by astronomers. Since they are used, they are 
>> published and they will go  in the  VO...
>
>
> Let me rephrase my first sentence:
> Hopefully, it is rare that one only has the upper lmit  but no info on 
> the actual readout or measured value of the upper limit point.
> So, we agree that upper limits are important scientifically.

Yes for the last sentence "we agree that upper limits are important 
scientifically."

>> I just wanted to comment that a value *measured* cannot be *below* 
>> the noise. Only the noise level is meaningfull in this case
>
>
> No!  Even a negative measurement on a property that is non-negative is 
> scientifically meaningful.  See below.
>
Well, but... (see below).

>> (the text notes, and this is customary indeed, that authors usually 
>> "choose to render measurements as upper limits if the flux value is 
>> less than some multiple (e.g. 3) of the lower error" (note: 
>> shouldn't  be *Upper* error? ) ). 
>
>
> You want the lower error bar to reach from the upper limit to the x-axis.
>
I think, in view of what you object, that I would prefer upper limits to 
have a different status than measure. Besides, I'm ill at ease thinking 
measure in geometrical terms (or, rather, in "plot+axis" terms), this 
looks too linked with our day to day external representation of data, (a 
mathematician would perhaps read "measure" as a "norm" for topology )

>> The risk would be, if any *measured* value is set, that is is taken 
>> at face value, when only the noise level has sense. Could you use 
>> some kind of blanking value for the measured value in this? (or is 
>> there a general concept of upper limit that would go in the 
>> Quantity::Accuracy data model?)
>>
> All I need say here is that if 4 independent experiments come up  
> with  0.9 sigma  detections of  some measurement that it would be 
> awful  if they each  published  only the upper limits of the value.

Here you suppose that the value "detected at 0.9 sigma" exists, or, 
rather, that I can pinpoint it in the graph, and put nice big errorbars 
on it for each of the 4 measurements. What I say is that this value does 
not exist until it is measured, and it is measured only when it is not 
an upper limit.
Of the 4 groups coming up with this "0.9 sigma detection", the 3 last in 
time are morons: they were not able to devise an experiment with less 
uncertainty as the 1st pioneering group. Shall we continue to support 
them financially? ;^). Besides, since the experiments are not the same, 
and you want to get a measurement at the end by averaging values+errors, 
you have to prove that errors and "measure" in those different 
experimental setups can be averaged. Unless the 4 experiments are just 4 
realizations of the 1st measurement, and, bingo, upper limits are still 
upper limits in this case....

Fortunately, for people bold enough to claim (and they are numerous!) 
that their 0.9 sigma measurement (was really an upper limit) _is_ a 
measurement, they can use the normal value+error scheme.

> The possibility that some moron may not look at the quoted noise 
> levels before coming to some silly conclusion on a measurment does not 
> compensate for missing out on  potentially important real discoveries 
> that properly archived data makes possible.

a) The possibility of "some moron..." is huge.
b) I would not place too much faith in discoveries (real, important) 
based on a sum of  invalid measurements...


Best,
Gilles

From owner-dm@eso.org  Mon Nov 22 21:11:26 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMKB9Tj018994
	for <dm-outgoing@mercury.hq.eso.org>; Mon, 22 Nov 2004 21:11:09 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAMKB9lr018992
	for dm-outgoing; Mon, 22 Nov 2004 21:11:09 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMKB3Tj018981;
	Mon, 22 Nov 2004 21:11:04 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMKB12i026489;
	Mon, 22 Nov 2004 21:11:01 +0100 (CET)
Received: from dropbox.aoc.nrao.edu (dropbox [146.88.1.13])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id iAMKArr32523;
	Mon, 22 Nov 2004 13:10:53 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by dropbox.aoc.nrao.edu (8.12.8/8.12.8/smtp-gateway) with ESMTP id iAMKApw5005651;
	Mon, 22 Nov 2004 13:10:52 -0700
Date: Mon, 22 Nov 2004 13:10:51 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: David Berry <dsb@ast.man.ac.uk>
cc: dal@ivoa.net, <dm@ivoa.net>
Subject: Re: SED data model v0.92
In-Reply-To: <Pine.OSF.4.53.0411190817330.15228@axp0.ast.man.ac.uk>
Message-ID: <Pine.LNX.4.44.0411221243290.2656-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.2, required 7,
	BAYES_01 -5.40, IN_REP_TO -0.37, QUOTED_EMAIL_TEXT -0.38,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.22.20
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi David -

>From David Berry:
> Am I correcting in thinking that if the spectral coordinate
> is linear with channel number, you still have to supply all the spectral
> coordinate values explicitly, rather than just giving a scale and offset?

Yes, this is the case at present.   The main reason we did this was
to avoid getting into all the issues involved in specifying a general
spectral WCS.  A fully populated spectral coordinate vector is dead simple
but handles all the various cases (simple linear, irregularly sampled, log
lambda, polynomial fit, spline fit, etc.).  Plus the same approach works
consistently for the time axis and so forth.  Much spectral data in archives
is in this format, and probably all 1D spectral data can be represented in
this way.

It might be worthwhile to add support for a simple linear dispersion
(scale and offset) as a special case.  For the cost of slightly more
interface complexity we would gain some efficiency of representation.
But there is a good chance this would escalate and lead to reinventing
spectral WCS.  It might be better to keep it simple now, and just add
general support for FITS WCS later as we expand the VO data models and
XML representations to cover this area.

Note the FITS representation already supports the proposed FITS spectral
WCS, using the -TAB convention to map the WCS spectral coordinate onto
a field of the binary table.  Although we don't include real WCS support
in SSA currently, it should be easy to use the coordinate vector to build
a WCS on top of SSA data.

	- Doug


From owner-dal@eso.org  Mon Nov 22 21:58:03 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMKvmTj023080
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 22 Nov 2004 21:57:48 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAMKvmWG023079
	for dal-outgoing; Mon, 22 Nov 2004 21:57:48 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMKvfTj023068;
	Mon, 22 Nov 2004 21:57:41 +0100 (MET)
Received: from curlew.cs.man.ac.uk (curlew.cs.man.ac.uk [130.88.13.7])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAMKvd2i027878;
	Mon, 22 Nov 2004 21:57:39 +0100 (CET)
Received: from axp0.ast.man.ac.uk ([130.88.9.45])
	by curlew.cs.man.ac.uk with esmtp (Exim 4.20)
	id 1CWLFi-000Jvj-MJ; Mon, 22 Nov 2004 20:57:38 +0000
Received: from dsb (helo=localhost)
	by axp0.ast.man.ac.uk with local-esmtp (Exim 2.12 #1)
	id 1CWLFi-0000xu-00; Mon, 22 Nov 2004 20:57:38 +0000
Date: Mon, 22 Nov 2004 20:57:37 +0000 (GMT)
From: David Berry <dsb@ast.man.ac.uk>
To: Doug Tody <dtody@nrao.edu>
cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
In-Reply-To: <Pine.LNX.4.44.0411221243290.2656-100000@oak>
Message-ID: <Pine.OSF.4.53.0411222025050.20269@axp0.ast.man.ac.uk>
References: <Pine.LNX.4.44.0411221243290.2656-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1CWLFi-000Jvj-MJ*BvgLzvHqtF.*
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.22.20
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: David Berry <dsb@ast.man.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Doug,

> > Am I correcting in thinking that if the spectral coordinate
> > is linear with channel number, you still have to supply all the spectral
> > coordinate values explicitly, rather than just giving a scale and offset?
>
> Yes, this is the case at present.   The main reason we did this was
> to avoid getting into all the issues involved in specifying a general
> spectral WCS.

Would you really need to do this up front? The approach Jonathan I have
been looking at in the IVOA Mapping class (see
http://hea-www.harvard.edu/~jcm/vo/docs/map.pdf)
is to view a Mapping as a black box which has a certain number of inputs
and a certain number of outputs (one of each in the case of simple
spectra). The recipe which is used to transform an input value into an
output value is encapsulated entirely within the Mapping object. Using
this idea within the spectral data model would just mean providing a place
holder for a Mapping object somewhere. The only thing which you need
specify about the Mapping in the spectral data model schema is that it has
one input (corresponding to channel number) and one output (corresponding
to the spectral coordinate value). Is there any need to specify anything
at all about *how* the output is derived from the input (i.e. about the
nature of the recipe encapsulated within the Mapping)? Can that not be
left up to the person creating the spectrum? Do we need to follow the
FITS-WCS route of demanding that only a small number of "blessed" recipes
be allowed?


David

From owner-dm@eso.org  Tue Nov 23 15:32:33 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iANEUBZI028058
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 23 Nov 2004 15:30:11 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iANEUBDn028057
	for dm-outgoing; Tue, 23 Nov 2004 15:30:11 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iANEU0ZI028020;
	Tue, 23 Nov 2004 15:30:01 +0100 (MET)
Received: from earth.astro.umd.edu (earth.astro.umd.edu [129.2.14.2])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iANETw2i002077;
	Tue, 23 Nov 2004 15:29:59 +0100 (CET)
Received: from [129.2.15.121] (lap40.astro.umd.edu [129.2.15.121])
	by earth.astro.umd.edu (Postfix) with ESMTP
	id 21DFB2C442; Tue, 23 Nov 2004 09:29:57 -0500 (EST)
Message-ID: <41A34963.7090009@gsfc.nasa.gov>
Date: Tue, 23 Nov 2004 09:29:55 -0500
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
Cc: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov> <419E335A.3000602@obs.ujf-grenoble.fr> <419E4671.9060606@gsfc.nasa.gov> <41A20813.5030902@obs.ujf-grenoble.fr>
In-Reply-To: <41A20813.5030902@obs.ujf-grenoble.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.22.52
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Gilles DUVERT wrote:

>
>
> Ed Shaya wrote:
>
>>
>> You want the lower error bar to reach from the upper limit to the 
>> x-axis.
>>
> I think, in view of what you object, that I would prefer upper limits 
> to have a different status than measure. Besides, I'm ill at ease 
> thinking measure in geometrical terms (or, rather, in "plot+axis" 
> terms), this looks too linked with our day to day external 
> representation of data, (a mathematician would perhaps read "measure" 
> as a "norm" for topology )
>
Although it makes the model more complicated, it is probably worth 
having an  UpperLimitPoint and a LowerLimitPoint which contains only the 
limit to be used ONLY when the limit value is not known.  It could have 
an optional  NSigma which tells  how many sigma limit was used and the 
default should be 3.  This way one does not confuse the upper limit 
magnitude with the true error value or the true value.

>>> The risk would be, if any *measured* value is set, that is is taken 
>>> at face value, when only the noise level has sense. Could you use 
>>> some kind of blanking value for the measured value in this? (or is 
>>> there a general concept of upper limit that would go in the 
>>> Quantity::Accuracy data model?)
>>>
>> All I need say here is that if 4 independent experiments come up  
>> with  0.9 sigma  detections of  some measurement that it would be 
>> awful  if they each  published  only the upper limits of the value.
>
>
> Here you suppose that the value "detected at 0.9 sigma" exists, or, 
> rather, that I can pinpoint it in the graph, and put nice big 
> errorbars on it for each of the 4 measurements. What I say is that 
> this value does not exist until it is measured, and it is measured 
> only when it is not an upper limit.


Are we having some subtle argument about when a measurement is a 
measurement and when a detection is a detection?
If I measure 9 photons in a pixel but the sky noise is 10 photons  we 
keep track of those 9 photons by placing it in the point/value just like 
any other measured value.
With just this measurement it is not a detection of anything except for 
those 9 photons, but  if  I  go back through the archives and find that 
this location has been studied 3 times before, perhaps with different 
filters, and each time this location has roughly 1 sigma positive 
measurements, then I would say that an object is detected at roughly 4 
sigma and my observation was just a 0.9 sigma detection.  Perhaps you 
would phrase this differently.
But, I hope that you are not supporting the idea that the USUAL 
treatment for a  measurement that is  less than  3 sigma should be to 
drop the value and just quote the upper limit.
You would not support blanking out all of the pixels in an image or 
spectrum where the signal is below 3 times the sky noise and replace 
them with upper limit values?  Or, would you?  We would need to 
reprocess all existing data archives to treat upper limits in this way?
If 4 major physics laboratories come up with 1 sigma detections of the 
mass of the neutrino at about 10eV should each publish just upper limits?

>
> Of the 4 groups coming up with this "0.9 sigma detection", the 3 last 
> in time are morons: they were not able to devise an experiment with 
> less uncertainty as the 1st pioneering group. Shall we continue to 
> support them financially? ;^). 

That is a political statement.

> Besides, since the experiments are not the same, and you want to get a 
> measurement at the end by averaging values+errors, you have to prove 
> that errors and "measure" in those different experimental setups can 
> be averaged. Unless the 4 experiments are just 4 realizations of the 
> 1st measurement, and, bingo, upper limits are still upper limits in 
> this case....
>
We certainly need to have a system so that if the same measurement shows 
up in several context that we and our applications can easily recognize 
it.  That is the point of putting IDs on observations.
Beyond that, it is the job of a distributed data system  to  be able to  
pull together similar  data entities for  processing.  Isn't the idea of 
the VO to allow us to do analyses across multiple data sets and data 
archives that is beyond our present capabilities.

> Fortunately, for people bold enough to claim (and they are numerous!) 
> that their 0.9 sigma measurement (was really an upper limit) _is_ a 
> measurement, they can use the normal value+error scheme.

This should be the normal mode and our applications should be upgraded 
to recognize measurements below 3 sigma and plot them as yellow and 
properly draw the upper limit symbol.

>
>> The possibility that some moron may not look at the quoted noise 
>> levels before coming to some silly conclusion on a measurment does 
>> not compensate for missing out on  potentially important real 
>> discoveries that properly archived data makes possible.
>
>
> a) The possibility of "some moron..." is huge.

Oh yes!  This is a tradeoff between a bunch of people wasting some time 
against losing precious perhaps irretrievable information.

> b) I would not place too much faith in discoveries (real, important) 
> based on a sum of  invalid measurements...
>
This is the crux of it.  To me, a less than 3 sigma measurement is a 
valid measurement.  It tells me  the probability of something being 
there so that I can properly assess my risks in attempting to go deeper 
in that direction.  If it is an invalid measurement then I don't want it 
published at all anywhere.

>
> Best,
> Gilles
>
Cheers,
Ed

From owner-dal@eso.org  Wed Nov 24 17:30:54 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAOGUQR8007615
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 24 Nov 2004 17:30:26 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAOGUQ1I007614
	for dal-outgoing; Wed, 24 Nov 2004 17:30:26 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAOGUER8007567;
	Wed, 24 Nov 2004 17:30:14 +0100 (MET)
Received: from amazone.ujf-grenoble.fr (amazone.ujf-grenoble.fr [193.54.238.254])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAOGUB2i026849;
	Wed, 24 Nov 2004 17:30:12 +0100 (CET)
Received: from tibre2.ujf-grenoble.fr (tana2.ujf-grenoble.fr [152.77.24.22])
	by amazone.ujf-grenoble.fr (Switch-3.1.3/Switch-3.1.0/Configured  by JE 9 8 2004) with ESMTP id iAOGTsOP002630;
	Wed, 24 Nov 2004 17:29:55 +0100 (CET)
Received: from gagax1.obs.ujf-grenoble.fr (gagax1.obs.ujf-grenoble.fr [195.220.79.11])
	by tibre2.ujf-grenoble.fr (8.12.8p1/8.12.8) with ESMTP id iAOGTsWS054614;
	Wed, 24 Nov 2004 17:29:54 +0100 (CET)
	(envelope-from Gilles.Duvert@obs.ujf-grenoble.fr)
Received: from [193.54.238.142] (jmmc1.ujf-grenoble.fr [193.54.238.142])
	by gagax1.obs.ujf-grenoble.fr (AIX4.3/UCB 8.8.8/8.8.5) with ESMTP id RAA98896;
	Wed, 24 Nov 2004 17:29:54 +0100
Message-ID: <41A4B701.2080800@obs.ujf-grenoble.fr>
Date: Wed, 24 Nov 2004 17:29:53 +0100
From: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
CC: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov> <419E335A.3000602@obs.ujf-grenoble.fr> <419E4671.9060606@gsfc.nasa.gov> <41A20813.5030902@obs.ujf-grenoble.fr> <41A34963.7090009@gsfc.nasa.gov>
In-Reply-To: <41A34963.7090009@gsfc.nasa.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.23.51
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Ed Shaya wrote:

> Gilles DUVERT wrote:
>
>>
>>
>> Ed Shaya wrote:
>>
>>>
>>> You want the lower error bar to reach from the upper limit to the 
>>> x-axis.
>>>
>> I think, in view of what you object, that I would prefer upper limits 
>> to have a different status than measure. Besides, I'm ill at ease 
>> thinking measure in geometrical terms (or, rather, in "plot+axis" 
>> terms), this looks too linked with our day to day external 
>> representation of data, (a mathematician would perhaps read "measure" 
>> as a "norm" for topology )
>>
> Although it makes the model more complicated, it is probably worth 
> having an  UpperLimitPoint and a LowerLimitPoint which contains only 
> the limit to be used ONLY when the limit value is not known.  It could 
> have an optional  NSigma which tells  how many sigma limit was used 
> and the default should be 3.  This way one does not confuse the upper 
> limit magnitude with the true error value or the true value.

now that you phrase it in DM words, it indeed complicates the model...

>
>>>> The risk would be, if any *measured* value is set, that is is taken 
>>>> at face value, when only the noise level has sense. Could you use 
>>>> some kind of blanking value for the measured value in this? (or is 
>>>> there a general concept of upper limit that would go in the 
>>>> Quantity::Accuracy data model?)
>>>>
>>> All I need say here is that if 4 independent experiments come up  
>>> with  0.9 sigma  detections of  some measurement that it would be 
>>> awful  if they each  published  only the upper limits of the value.
>>
>>
>>
>> Here you suppose that the value "detected at 0.9 sigma" exists, or, 
>> rather, that I can pinpoint it in the graph, and put nice big 
>> errorbars on it for each of the 4 measurements. What I say is that 
>> this value does not exist until it is measured, and it is measured 
>> only when it is not an upper limit.
>
>
>
> Are we having some subtle argument about when a measurement is a 
> measurement and when a detection is a detection?
> If I measure 9 photons in a pixel but the sky noise is 10 photons  we 
> keep track of those 9 photons by placing it in the point/value just 
> like any other measured value.
> With just this measurement it is not a detection of anything except 
> for those 9 photons, but  if  I  go back through the archives and find 
> that this location has been studied 3 times before, perhaps with 
> different filters, and each time this location has roughly 1 sigma 
> positive measurements, then I would say that an object is detected at 
> roughly 4 sigma and my observation was just a 0.9 sigma detection.  
> Perhaps you would phrase this differently.
> But, I hope that you are not supporting the idea that the USUAL 
> treatment for a  measurement that is  less than  3 sigma should be to 
> drop the value and just quote the upper limit.
> You would not support blanking out all of the pixels in an image or 
> spectrum where the signal is below 3 times the sky noise and replace 
> them with upper limit values?  Or, would you?  We would need to 
> reprocess all existing data archives to treat upper limits in this way?
> If 4 major physics laboratories come up with 1 sigma detections of the 
> mass of the neutrino at about 10eV should each publish just upper limits?
>
Well, your example is good and I certainly  do not want to drop all 
experiments below the 3 sigma limit !. But I was not claiming the SED 
datamodel does not describe properly measurements, on the contary! ( I 
would just *force* each Flux.StatErrXXX to be present and non-zero, 
instead of being optional and zero by default, because this *is* how a 
measurement *must be*).
No, I was discussing the fact that UpperLimits [of non-detections] 
cannot be expressed that way, and at the same time retain meaningfulness:
Simple detectors such as camera pixels counting photoevents in your 
example are just too easy to deal with...  Imagine you  map a region of  
interest in radio interferometry, nothing evident in the maps, yet you 
know there is a source at some position already detected at other 
wavelengths. You can fit a point source model in the visibilities, even 
force it to be at the source position. The fit may not converge. You 
have not measured anything, but you can still give an upper limit  
either based on the rms of the map or (more accurately) on the sensivity 
of the instrument given the total integration time, etc... People do 
that all the time. Where is the pixel with the actual photoevent count? 
Will the SED DM force radioastronomers to transform their (valuable) 
non-detection into a value+errorbar? with which value?

So the point is, "are all SED-related measurements expressible in terms 
of value+errorbar?", and I say no for detection limits. Data producers 
should carefully choose whatever corresponds most to their data between 
( Flux.value + Flux.StatErrXXX ) or Flux.UpperLimit ( or  
Flux.DetectionThreshold) .

>>
>> Of the 4 groups coming up with this "0.9 sigma detection", the 3 last 
>> in time are morons: they were not able to devise an experiment with 
>> less uncertainty as the 1st pioneering group. Shall we continue to 
>> support them financially? ;^). 
>
>
> That is a political statement.

(but with a smiley)

>
>> Besides, since the experiments are not the same, and you want to get 
>> a measurement at the end by averaging values+errors, you have to 
>> prove that errors and "measure" in those different experimental 
>> setups can be averaged. Unless the 4 experiments are just 4 
>> realizations of the 1st measurement, and, bingo, upper limits are 
>> still upper limits in this case....
>>
> We certainly need to have a system so that if the same measurement 
> shows up in several context that we and our applications can easily 
> recognize it.  That is the point of putting IDs on observations.
> Beyond that, it is the job of a distributed data system  to  be able 
> to  pull together similar  data entities for  processing.  Isn't the 
> idea of the VO to allow us to do analyses across multiple data sets 
> and data archives that is beyond our present capabilities.

the point here is how (difficult it is) to recognize if data is "similar"

>
>> Fortunately, for people bold enough to claim (and they are numerous!) 
>> that their 0.9 sigma measurement (was really an upper limit) _is_ a 
>> measurement, they can use the normal value+error scheme.
>
>
> This should be the normal mode and our applications should be upgraded 
> to recognize measurements below 3 sigma and plot them as yellow and 
> properly draw the upper limit symbol.

yes

>
>>
>>> The possibility that some moron may not look at the quoted noise 
>>> levels before coming to some silly conclusion on a measurment does 
>>> not compensate for missing out on  potentially important real 
>>> discoveries that properly archived data makes possible.
>>
>>
>>
>> a) The possibility of "some moron..." is huge.
>
>
> Oh yes!  This is a tradeoff between a bunch of people wasting some 
> time against losing precious perhaps irretrievable information.

What i meant is that in every astronomer using VO services there may be 
a potential moron since, however smart I am, I will be as dumb as the 
dumbest part of the chain  of software+specifications+documentation that 
conveys the data to me. If the DM is not accurate/clear enough, data 
producers may not be able to use the most appropriate tag for their 
data, data retrieval programs may misinterpret "measure" with "upper 
limits", overlook "errors", users may not be able to realize through the 
human-readable interface what was overlooked or misintrepreted.
This to stress only the importance of the work done on DMs as basements 
of the VO. (and praise those that concieve them!).

>> b) I would not place too much faith in discoveries (real, important) 
>> based on a sum of  invalid measurements...
>>
> This is the crux of it.  To me, a less than 3 sigma measurement is a 
> valid measurement.  It tells me  the probability of something being 
> there so that I can properly assess my risks in attempting to go 
> deeper in that direction.  If it is an invalid measurement then I 
> don't want it published at all anywhere.

I agree completely with the above sentence. Again, the point was not on 
the use of a valid pair (measurement+1sigma error) , but on the 
properties of UpperLimits that do not follow this scheme.

>
>>
>> Best,
>> Gilles
>>
> Cheers,
> Ed

Best,

Gilles

From owner-dm@eso.org  Wed Nov 24 22:01:40 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAOL1MR8028329
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 24 Nov 2004 22:01:22 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iAOL1MMw028328
	for dm-outgoing; Wed, 24 Nov 2004 22:01:22 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAOL1HR8028312;
	Wed, 24 Nov 2004 22:01:17 +0100 (MET)
Received: from earth.astro.umd.edu (earth.astro.umd.edu [129.2.14.2])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iAOL1FRQ008232;
	Wed, 24 Nov 2004 22:01:16 +0100 (CET)
Received: from [129.2.15.121] (lap40.astro.umd.edu [129.2.15.121])
	by earth.astro.umd.edu (Postfix) with ESMTP
	id D51B62C461; Wed, 24 Nov 2004 16:01:14 -0500 (EST)
Message-ID: <41A4F698.4080001@gsfc.nasa.gov>
Date: Wed, 24 Nov 2004 16:01:12 -0500
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
Cc: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov> <419E335A.3000602@obs.ujf-grenoble.fr> <419E4671.9060606@gsfc.nasa.gov> <41A20813.5030902@obs.ujf-grenoble.fr> <41A34963.7090009@gsfc.nasa.gov> <41A4B701.2080800@obs.ujf-grenoble.fr>
In-Reply-To: <41A4B701.2080800@obs.ujf-grenoble.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.11.24.19
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Gilles,
    We seem to agree now.  Perhaps we always did.
Ed


From owner-dm@eso.org  Mon Dec  6 10:13:59 2004
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iB69Ddkp012576
	for <dm-outgoing@mercury.hq.eso.org>; Mon, 6 Dec 2004 10:13:39 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iB69DcP7012575
	for dm-outgoing; Mon, 6 Dec 2004 10:13:38 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iB69DPkp012534;
	Mon, 6 Dec 2004 10:13:26 +0100 (MET)
Received: from amazone.ujf-grenoble.fr (amazone.ujf-grenoble.fr [193.54.238.254])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iB69DORQ008851;
	Mon, 6 Dec 2004 10:13:24 +0100 (CET)
Received: from tibre1.ujf-grenoble.fr (tana1.ujf-grenoble.fr [152.77.18.74])
	by amazone.ujf-grenoble.fr (Switch-3.1.3/Switch-3.1.0/Configured  by JE 9 8 2004) with ESMTP id iB69Cww9001894;
	Mon, 6 Dec 2004 10:12:58 +0100 (CET)
Received: from gagax1.obs.ujf-grenoble.fr (gagax1.obs.ujf-grenoble.fr [195.220.79.11])
	by tibre1.ujf-grenoble.fr (8.12.8p1/8.12.8) with ESMTP id iB69D32N056222;
	Mon, 6 Dec 2004 10:13:03 +0100 (CET)
	(envelope-from Gilles.Duvert@obs.ujf-grenoble.fr)
Received: from [193.54.238.142] (jmmc1.ujf-grenoble.fr [193.54.238.142])
	by gagax1.obs.ujf-grenoble.fr (AIX4.3/UCB 8.8.8/8.8.5) with ESMTP id KAA38452;
	Mon, 6 Dec 2004 10:12:57 +0100
Message-ID: <41B42299.6020007@obs.ujf-grenoble.fr>
Date: Mon, 06 Dec 2004 10:12:57 +0100
From: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
CC: Jonathan McDowell <jcm@head.cfa.harvard.edu>, dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov> <419E335A.3000602@obs.ujf-grenoble.fr> <419E4671.9060606@gsfc.nasa.gov> <41A20813.5030902@obs.ujf-grenoble.fr> <41A34963.7090009@gsfc.nasa.gov> <41A4B701.2080800@obs.ujf-grenoble.fr> <41A4F698.4080001@gsfc.nasa.gov>
In-Reply-To: <41A4F698.4080001@gsfc.nasa.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.12.5.11
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Sorry for the long blackout. More pressing matters, not Alzheimer (I 
think).
Did you say you agree that the property Flux.DetectionThreshold can be 
present (and can be present even without [ Flux.value + Flux.StatErrXXX ])?
Best
Gilles

Ed Shaya wrote:

> Gilles,
>    We seem to agree now.  Perhaps we always did.
> Ed
>
>

From owner-dal@eso.org  Mon Dec  6 16:32:49 2004
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iB6FWXkp004548
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 6 Dec 2004 16:32:33 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id iB6FWXNS004547
	for dal-outgoing; Mon, 6 Dec 2004 16:32:33 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iB6FWNkp004489;
	Mon, 6 Dec 2004 16:32:24 +0100 (MET)
Received: from earth.astro.umd.edu (earth.astro.umd.edu [129.2.14.2])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id iB6FWL2i026883;
	Mon, 6 Dec 2004 16:32:22 +0100 (CET)
Received: from [129.2.15.121] (lap40.astro.umd.edu [129.2.15.121])
	by earth.astro.umd.edu (Postfix) with ESMTP
	id 21DB32C493; Mon,  6 Dec 2004 10:32:16 -0500 (EST)
Message-ID: <41B47B7B.6000301@gsfc.nasa.gov>
Date: Mon, 06 Dec 2004 10:32:11 -0500
From: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707
X-Accept-Language: en-us, en
MIME-Version: 1.0
Cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED data model v0.92
References: <200411190616.iAJ6GHDc017428@urania.cfa.harvard.edu> <419E07AF.1060903@gsfc.nasa.gov> <419E335A.3000602@obs.ujf-grenoble.fr> <419E4671.9060606@gsfc.nasa.gov> <41A20813.5030902@obs.ujf-grenoble.fr> <41A34963.7090009@gsfc.nasa.gov> <41A4B701.208 <41B42299.6020007@obs.ujf-grenoble.fr>
In-Reply-To: <41B42299.6020007@obs.ujf-grenoble.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.12.5.11
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Ed Shaya <edward.j.shaya.1@gsfc.nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Gilles,

   Yes.  The schema should certainly allow for upper and lower limits 
alone (flux.detectionThreshold is fine in spectra and images, and one 
may need another thing for saturation level which results in knowledge 
of only an upper limit).  It is necessary for both legacy data in which 
the value and error are simply lost forever and for experiments in which 
there is no clearcut algorithm to estimate a value.

Our disagreement amounts to the fact that I would encourage the observer 
to use value and error if at all possible, and you seem to encourage use 
of the fluxDetectionThreshold.  In the end, it is not up to us anyway.  
  It would be up to the observer/experimenter to decide which is 
appropriate.  

Ed

Gilles DUVERT wrote:

> Sorry for the long blackout. More pressing matters, not Alzheimer (I 
> think).
> Did you say you agree that the property Flux.DetectionThreshold can be 
> present (and can be present even without [ Flux.value + 
> Flux.StatErrXXX ])?
> Best
> Gilles
>
> Ed Shaya wrote:
>
>> Gilles,
>>    We seem to agree now.  Perhaps we always did.
>> Ed
>>
>>
>
>

From owner-dal@eso.org  Wed Jan  5 20:49:30 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j05Jmivr013648
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 5 Jan 2005 20:48:45 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j05JmioV013647
	for dal-outgoing; Wed, 5 Jan 2005 20:48:44 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j05JmLvr013568;
	Wed, 5 Jan 2005 20:48:21 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j05JmIhA010981;
	Wed, 5 Jan 2005 20:48:19 +0100 (CET)
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head.cfa.harvard.edu (d/w) with ESMTP id j05JmDKD009537;
	Wed, 5 Jan 2005 14:48:13 -0500 (EST)
From: Arnold Rots <arots@head.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id j05JmCX9026705;
	Wed, 5 Jan 2005 14:48:12 -0500 (EST)
Message-Id: <200501051948.j05JmCX9026705@xebec.cfa.harvard.edu>
Subject: STC Version 1.10
To: dal@ivoa.net, dm@ivoa.net, dm-catalog@ivoa.net, registry@ivoa.net,
        voql@ivoa.net, votable@ivoa.net
Date: Wed, 5 Jan 2005 14:48:12 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.1.5.17
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Arnold Rots <arots@head.cfa.harvard.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

With apologies for the wide distribution - many of you will get
multiple copies of this message.  But STC does touch on many areas.


STC Version 1.10 has been posted at ivoa.net.

The Working Draft and the schemata have been modified following
comments, mainly by Anita Richards and David Berry.

The most important changes:

  Pixel Space specification
  Allow UNKNOWN for certain elements
  Allow ranges for Coordinate components other than Name and Value
  Provide for the specification of rest frequencies
  Improved generalization, inheritance, polymorphism
  Added AllSky to Region shapes

In addition, I have compiled a document that describes the XML
implementation.
This really completes the first release.  I consider this
implementation a stable version and do not envision any drastic
changes until Version 2.0.

And I have created a project page at us-vo.org:

	http://us-vo.org/projects/project.cfm?ID=62

There will be a poster on STC V1.10 at the AAS special session, next week.

Cheers,

  - Arnold

--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

----- End of forwarded message from Arnold Rots -----
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From owner-dm@eso.org  Sat Jan 22 05:20:12 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j0M4JrxZ015955
	for <dm-outgoing@mercury.hq.eso.org>; Sat, 22 Jan 2005 05:19:54 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j0M4Jrhr015954
	for dm-outgoing; Sat, 22 Jan 2005 05:19:53 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j0M4JoxZ015949;
	Sat, 22 Jan 2005 05:19:50 +0100 (MET)
Received: from sn.sai.msu.ru (sn.sai.msu.ru [195.208.220.215])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j0M4Jm57008062;
	Sat, 22 Jan 2005 05:19:48 +0100 (CET)
Received: from sn.sai.msu.ru (localhost [127.0.0.1])
	by sn.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j0M4Idfs021795;
	Sat, 22 Jan 2005 07:18:39 +0300
Received: from localhost (chil@localhost)
	by sn.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j0M4IdGN021792;
	Sat, 22 Jan 2005 07:18:39 +0300
X-Authentication-Warning: sn.sai.msu.ru: chil owned process doing -bs
Date: Sat, 22 Jan 2005 07:18:39 +0300 (MSK)
From: "Igor V. Chilingarian" <chil@sai.msu.ru>
To: dal@ivoa.net, dm@ivoa.net
Subject: SED Data Model: Questions and Comments
Message-ID: <Pine.LNX.4.58.0501220711140.6786@sn.sai.msu.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.1.21.9
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: "Igor V. Chilingarian" <chil@sai.msu.ru>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hello,

During last month I've been working on SSA services for the Observatoire de
Paris, so I had to study exhaustively the SED Data Model draft v0.92
( http://hea-www.harvard.edu/~jcm/vo/docs/spec.html ). I have some comments,
questions, and suggestions concerning this document. They may be separated
into two parts: technical and ideological (comments made by me as by an
astronomer working in optical integral field spectroscopy).

I'll start with technical problems and questions.

1/ While in the paragraph about FITS serialization it is written that
dimensional equations are required, in the paragraph about Frame object it is
said that all the Frame fields are optional.

2/ Some "required" DM fields don't have corresponding FITS keywords in
the translation tables:
        Coverage.Location.Time.Value
        Coverage.Extent.*

3/ What is "Coverage.Exposure" -> "EXPOSURE"? It appears only in the
FITS<->DM translation tables

4/ While the UML class diagram shows inheritance(?) of SEDCoord type by
Coverage.Location.[Sky,Time,Spectral],
Coverage.Location.[Sky,Time,Spectral].Value's are declared as "Position"
and "TextParam" in the XML schema. Should they be "SEDCoord"?

==================
Now some ideological aspects.

1/ The most important problem is handling the spectra expressed in the
continuum-normalized fluxes. Many astronomers, especially ones working in
stellar physics, absolutely don't care about flux calibration. They prefer
to use continuum-normalized spectra, because it allows to measure easily
equivalent widths of absorption lines, fluxes of emission lines, etc.
Presently there is even no UCD (though it can be constructed) to describe
this sort of data, though zillions of spectra (especially high-SN
high-resolution Echelle) are available in this format. The
continuum-normalized representation is also very useful for comparing
spectra of different objects of different brightnesses.

We tried to discuss this question on the VO-related seminary in the
Observatoire de Paris two days ago, and all the astronomers agreed that
continuum-normalized spectrum is a very important particular case of the
spectra representation, and it should be separated from, say general
not-calibrated data. There should be UCD especially for this data type.

2/ How is it possible to describe the spectral data, where the flux
calibration is not absolute (i.e. the "shape" of the spectrum is correct,
and "counts" in any wavelength channel have the same ratio to F_nu or
F_lambda, but this ratio is unknown, or known with an awful precision)? This
is a very typical case for ground-based observations, for example if you
observe with a narrow slit, and seeing changes in time, the calibration
you'll get will be wrong, but spectra are still useful for numerous
astrophysical applications, such as spectral synthesis. In other words, the
problem is to describe SED in physical flux, but without absolute
calibration. In terms of Osuna-Saldago dimensional/scale equations it means
that we DO have the dimensional equation, but we don't have scale equation
for flux, e.g. "1.E+7 ML-1T-3" -> "Unknown ML-1T-3". So, my suggestion is to
remove the constrain for scale equation. If one provides the scale
coefficient, it should be used by the client, but is it not provided, there
should be a way to enter it (manually and/or automatically).

3/ Atmosphere and vacuum wavelengths. Probably it is not a question for DM
and DAL groups, because the possibility of having any of them is asserted in
the present draft. But how one can handle this? Optical astronomers will
never accept 6564.7A as Halpha wavelength (in vacuum), because everybody
knows that Halpha is 6562.85A (air wavelength)! For a moment (in SDM v0.92)
usage of AWAV is not recommended. The possible solution is to use wave
numbers or frequencies, that don't depend on the refraction coefficient, but
optical astronomers will not accept this! They don't even accept nanometers
instead of Angstroms. This raises a question of coding the rule for
converting AWAV<->WAV. Should it be specified in the metadata, or it should
considered as "well-known" on the side of VO clients, or we should provide,
say WEB-Service doing the job?

4/ Precise description of the spectral resolution . I raised this question
for a couple of times, so to make the data model self-sufficient, it is a
good idea to be able to describe in details the line-spread-function, that
may vary through the wavelength range, and may be quite complex (neither
Gaussian, nor Lorentzian). The function itself may be described in the
similar way to the transparency curve of the filter (for future, maybe even
for SDM v.2).

For a moment (for SDM 1.0) I'd like to propose to complicate the
"Resolution" field of the "Accuracy" object to add 2-, 4-, or 6-parametric
description of the line-spread function beside FWHM. What I mean is
Gauss-Hermite representation (van der Marel, Franx, 1993ApJ...407..525V):
the approach used by astronomers dealing with stellar kinematics of the
galaxies to describe LOSVD. The line-spread function can be described by 2,
4 or 6 parameters: dl (systematic shift in spectral coordinate), sigma
(dispersion of the approximate Gaussian) [, h3, h4 [,h5 ,h6] : Hermite
polynomials coefficients, describing deviations from Gaussian shape].
Usually 4 parameters are used, because one needs very good sampling and high
S/N ratio to extract h5 and h6 from observational data. In this case,
Resolution.FWHM can be computed.  On the other hand, this 6-param
representation should not be an obligation (as the "Resolution" object
itself): one may want to use only FWHM.

The XML-schema would be changed in the following way:

  <!-- A single SEDCoord (time or spectral coord) value. -->

  <xs:complexType name="SEDCoord">
    <xs:complexContent mixed="false">
      <xs:extension base="Group">
        <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" name="Value" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="Accuracy" type="Accuracy" />
          <xs:element minOccurs="0" maxOccurs="1" name="Resolution" type="Resolution" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="Resolution">
    <xs:complexContent mixed="false">
      <xs:extension base="Group">
        <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" name="FWHM" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="ResolutionGH" type="ResolutionGH" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="ResolutionGH">
    <xs:complexContent mixed="false">
      <xs:extension base="Group">
        <xs:sequence>
          <xs:element minOccurs="0" maxOccurs="1" name="dl" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="sigma" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h3" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h4" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h5" type="DoubleParam" />
          <xs:element minOccurs="0" maxOccurs="1" name="h6" type="DoubleParam" />
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


That's all for a moment. Probably I forgot something.
I appreciate if you're still reading this :)

With best regards,
						Igor

From owner-dal@eso.org  Tue Feb  1 15:24:53 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11EMx10010993
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 15:22:59 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11EMxGZ010992
	for dal-outgoing; Tue, 1 Feb 2005 15:22:59 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11EMt10010986
	for <dal@ivoa.net>; Tue, 1 Feb 2005 15:22:55 +0100 (MET)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11EMr57019960
	for <dal@ivoa.net>; Tue, 1 Feb 2005 15:22:54 +0100 (CET)
Received: from [130.167.237.248] (atman.stsci.edu [130.167.237.248])
	by donner.stsci.edu (MOS 3.5.5-GR)
	with ESMTP id BGX09025;
	Tue, 1 Feb 2005 09:22:46 -0500 (EST)
Message-ID: <41FF90E7.5010406@stsci.edu>
Date: Tue, 01 Feb 2005 09:23:35 -0500
From: Randall Thompson <rthomp@stsci.edu>
Organization: STScI
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dal@ivoa.net
Subject: SED Data Model version 0.92
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Junkmail-Status: score=0/50, host=donner.stsci.edu
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.2
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Randall Thompson <rthomp@stsci.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi,
   I just  discovered the IVOA SED Data Model document version 0.92
and wanted to ask some questions about it. Since we have been anxiously
awaiting an SSAP for distributing spectral data from MAST, we were happy
to see progress being made.
    First of all, I am confused why the document has changed from the 
Simple
Spectral Data Model to the SED Data Model when it will be used to 
"represent
SED, spectra and time series data".  Do you plan to write separate 
documents for
each data type?
    Also, I am confused about the FITS serialization in section 8.1. Are 
you requiring
variable-length arrays and not allowing array fields within the binary 
table itself?
I would think not all data sets require variable-length arrays and the 
FITS standard even
recommends a simpler format when this feature is not necessary.
    Finally, I think there are errors in the sample FITS header shown. 
It look like
there are actually 15 fields, not 14 (there are 2 sets of TTYPE2 & 
TFORM2 keywords), and
there is no THEAP keyword describing the offset to the data heap. Unless 
the convention has
changed, this should have the value of NAXIS1 * NAXIS2 if there is no 
gap between the binary
table and the data heap.
    Sorry if these issues were already addressed.

Randy Thompson

From owner-dal@eso.org  Tue Feb  1 16:22:07 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11FL710021576
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 16:21:07 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11FL7sN021575
	for dal-outgoing; Tue, 1 Feb 2005 16:21:07 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11FL010021562
	for <dal@ivoa.net>; Tue, 1 Feb 2005 16:21:00 +0100 (MET)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11FKw57022085
	for <dal@ivoa.net>; Tue, 1 Feb 2005 16:20:58 +0100 (CET)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id j11FKiMi008727;
	Tue, 1 Feb 2005 08:20:44 -0700
Date: Tue, 1 Feb 2005 08:20:43 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Randall Thompson <rthomp@stsci.edu>
cc: dal@ivoa.net
Subject: Re: SED Data Model version 0.92
In-Reply-To: <41FF90E7.5010406@stsci.edu>
Message-ID: <Pine.LNX.4.44.0502010753480.15350-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.3
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Randy -

Thanks for taking a look at this and providing some feedback.

> I just  discovered the IVOA SED Data Model document version 0.92 and
> wanted to ask some questions about it. Since we have been anxiously
> awaiting an SSAP for distributing spectral data from MAST, we were happy
> to see progress being made.
> 
> First of all, I am confused why the document has changed from the Simple
> Spectral Data Model to the SED Data Model when it will be used to
> "represent SED, spectra and time series data".  Do you plan to write
> separate documents for each data type?

It is still called Simple Spectral Access and the "spectral data model"
is not restricted to SEDs.  SEDs, spectra, and time series are all
spectrophotometric (spectral) data.  Basically they are all sequences of
spectrophotometric data points, just organized in different ways.

There is no intention to write a different document for each of these
types of data although we do expect that service instances will generally
support only one type.  Accessing 1D spectrum is probably the most common
use case and the whole interface should reduce to something fairly simple
for this case.  (Although every time we have this discussion people want
to add more features to the model).

> Also, I am confused about the FITS serialization in section 8.1. Are
> you requiring variable-length arrays and not allowing array fields
> within the binary table itself?  I would think not all data sets require
> variable-length arrays and the FITS standard even recommends a simpler
> format when this feature is not necessary.

Good point, the document does talk explicitly about variable length arrays
and that should probably be revisited.  Whether a fixed or variable array
is used should probably be left up to the data provider.  Fixed arrays
are preferred where they are sufficient.  The data model does not care,
it is purely a representation issue.

> Finally, I think there are errors in the sample FITS header shown.
> It look like there are actually 15 fields, not 14 (there are 2 sets of
> TTYPE2 & TFORM2 keywords), and there is no THEAP keyword describing the
> offset to the data heap. Unless the convention has changed, this should
> have the value of NAXIS1 * NAXIS2 if there is no gap between the binary
> table and the data heap.

You are correct, this is an error.

	- Doug

From owner-apps@eso.org  Tue Feb  1 16:54:11 2005
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11Fs110027650
	for <apps-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 16:54:01 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11Fs0wK027649
	for apps-outgoing; Tue, 1 Feb 2005 16:54:00 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11Frj10027586;
	Tue, 1 Feb 2005 16:53:45 +0100 (MET)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11FrghA013035;
	Tue, 1 Feb 2005 16:53:43 +0100 (CET)
Received: from stsci.edu (obiwan.stsci.edu [130.167.236.123])
	by donner.stsci.edu (MOS 3.5.5-GR)
	with ESMTP id BGY00172;
	Tue, 1 Feb 2005 10:53:35 -0500 (EST)
Message-ID: <41FFA630.C3886D33@stsci.edu>
Date: Tue, 01 Feb 2005 10:54:24 -0500
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: dal@ivoa.net, dm@ivoa.net, apps@ivoa.net
CC: busko@stsci.edu
Subject: SSAP sample files
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Junkmail-Status: score=0/50, host=donner.stsci.edu
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.3
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Ivo Busko <busko@stsci.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Folks,

I am about to release a new version of Specview with
the ability to write spectrograms in SSAP format. 

However, before I do that, I would greatly appreciate
any comments, cristicisms and the like from the experts
out there. 

I tried to follow the specs in the SED Data  Model v 0.92.
I am sure there are things that are missing, misinterpreted 
by me, or plainly wrong, in my implementation. Thus, before 
releasing flawed code, it would be of great help to hear 
what people have to say about the files created by Specview.

To that end, I put a few samples at

http://specview.stsci.edu/SSAP/

They include a multi-instrument SED, a few orders of a HST 
STIS echelle spectrogram, two segments of an ISO-LWS spectrum,
a comparison between data and a template (from the AVO demo),
and a spectrum retrieved from the VOServices Web Services 
interface at http://www.voservices.org/.

FITS serialization will be added in a future release.

Regards,

-Ivo

 *********************************************************************
 *  Ivo C. Busko, PhD                        e-mail: busko@stsci.edu *
 *  Senior Systems Software Engineer                                 *
 *  Astronomy Tools and Applications                                 *
 *  Engineering and Software Services Division  Voice: (410)338-4472 *
 *  Space Telescope Science Institute             FAX: (410)338-4767 *
 *  3700 San Martin Drive                                            *
 *  Baltimore MD 21218-2410  USA                                     *
 *********************************************************************

From owner-dm@eso.org  Tue Feb  1 17:52:57 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11GqX10005965
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 17:52:33 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11GqX62005964
	for dm-outgoing; Tue, 1 Feb 2005 17:52:33 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11GqS10005949;
	Tue, 1 Feb 2005 17:52:29 +0100 (MET)
Received: from esa-av-smtp2.gmessaging.net (esa-av-smtp2.gmessaging.net [194.51.201.23])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11GqQ57025384;
	Tue, 1 Feb 2005 17:52:26 +0100 (CET)
Received: from esa-spas2.gmessaging.net (relay2 [172.24.21.39])
 by esa-av-smtp2.gmessaging.net
 (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
 with ESMTP id <0IB800FTTS7143@esa-av-smtp2.gmessaging.net>; Tue,
 01 Feb 2005 17:52:13 +0100 (MET)
Received: from localhost (esa-spas2 [127.0.0.1])	by esa-spas2.gmessaging.net
 (Postfix) with ESMTP	id 22DC9219E46; Tue, 01 Feb 2005 17:52:16 +0100 (CET)
Received: from esa-spas2.gmessaging.net ([127.0.0.1])
 by localhost (esa-spas2 [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 06365-05; Tue, 01 Feb 2005 17:52:15 +0100 (CET)
Received: from sciops-mailgw.vilspa.esa.int
 (sciops-mailgw.vilspa.esa.int [193.147.152.105])	by esa-spas2.gmessaging.net
 (Postfix) with ESMTP	id 8317B219E4A; Tue, 01 Feb 2005 17:52:15 +0100 (CET)
Received: from iso.vilspa.esa.es (isous5.vilspa.esa.es [193.147.153.100])
	by sciops-mailgw.vilspa.esa.int (Postfix) with ESMTP	id 0621D11F769; Tue,
 01 Feb 2005 17:52:16 +0100 (CET)
Received: from isol03.vilspa.esa.int (isol03.vilspa.esa.int [193.147.153.17])
	by iso.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id j11Gq6Tu004117; Tue,
 01 Feb 2005 17:52:06 +0100 (MET)
Date: Tue, 01 Feb 2005 17:52:06 +0100
From: Pedro Osuna <Pedro.Osuna@sciops.esa.int>
Subject: Re: SED Data Model version 0.92
In-reply-to: <Pine.LNX.4.44.0502010753480.15350-100000@lepus.tuc.noao.edu>
To: dal@ivoa.net, dm@ivoa.net
Cc: Pedro.Osuna@sciops.esa.int, Jesus.Salgado@sciops.esa.int,
        Christophe.Arviset@esa.int, Isa.Barbarisi@sciops.esa.int
Message-id: <1107276726.26799.6892.camel@isol03.vilspa.esa.int>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9)
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-Spam-Score: Content analysis details:   (-1.2 points,
 4.5 points required to be considered as spam) -1.2 BAYES_00
 BODY: Bayesian spam probability is 0 to 1%                            [score:
 0.0000] 0.1 AWL                    AWL: Auto-whitelist adjustment
References: <Pine.LNX.4.44.0502010753480.15350-100000@lepus.tuc.noao.edu>
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.3
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Pedro Osuna <Pedro.Osuna@sciops.esa.int>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear all,

there might be some confusion on the naming of the different things.

The Simple Spectrum Access Protocol refers to the protocol to access the
Spectra (as the SIAP does for images) whereas the SED Data Model
describes how those spectra should be modeled (to be compatible with the
IVOA specification).

The SSAP is not finished yet. There is only a version 0.1 document. We
have asked for the inclusion of a couple of dimensional parameters in
that protocol, and are already using it.

You can see a real service using SSAP registered data using our VOSpec
tool at:

http://esavo.esa.int/vospec/


When inputing a target and clicking "Go", the tool will access the NVO
Registry and get those services registered as giving SSAP access to
their data.

Among those services is the SLOAN spectrum service. This service is the
only one currently giving SED v0.9 compatible spectra (through an SSAP
protocol).

Therefore, we do have already a tool that accesses Spectra using
-current- SSAP and one of the services provides the Spectra in SED v0.9
compatible form.

As you can see, there are other five services giving SSAP access (ISO,
IUE, HST, FUSE, HyperLEDA) which do not -however- give their spectra in
SED v0.9 compatible form.

I hope this clarifies the issue.

Cheers,
P.




On Tue, 2005-02-01 at 16:20, Doug Tody wrote:
> Hi Randy -
> 
> Thanks for taking a look at this and providing some feedback.
> 
> > I just  discovered the IVOA SED Data Model document version 0.92 and
> > wanted to ask some questions about it. Since we have been anxiously
> > awaiting an SSAP for distributing spectral data from MAST, we were happy
> > to see progress being made.
> > 
> > First of all, I am confused why the document has changed from the Simple
> > Spectral Data Model to the SED Data Model when it will be used to
> > "represent SED, spectra and time series data".  Do you plan to write
> > separate documents for each data type?
> 
> It is still called Simple Spectral Access and the "spectral data model"
> is not restricted to SEDs.  SEDs, spectra, and time series are all
> spectrophotometric (spectral) data.  Basically they are all sequences of
> spectrophotometric data points, just organized in different ways.
> 
> There is no intention to write a different document for each of these
> types of data although we do expect that service instances will generally
> support only one type.  Accessing 1D spectrum is probably the most common
> use case and the whole interface should reduce to something fairly simple
> for this case.  (Although every time we have this discussion people want
> to add more features to the model).
> 
> > Also, I am confused about the FITS serialization in section 8.1. Are
> > you requiring variable-length arrays and not allowing array fields
> > within the binary table itself?  I would think not all data sets require
> > variable-length arrays and the FITS standard even recommends a simpler
> > format when this feature is not necessary.
> 
> Good point, the document does talk explicitly about variable length arrays
> and that should probably be revisited.  Whether a fixed or variable array
> is used should probably be left up to the data provider.  Fixed arrays
> are preferred where they are sufficient.  The data model does not care,
> it is purely a representation issue.
> 
> > Finally, I think there are errors in the sample FITS header shown.
> > It look like there are actually 15 fields, not 14 (there are 2 sets of
> > TTYPE2 & TFORM2 keywords), and there is no THEAP keyword describing the
> > offset to the data heap. Unless the convention has changed, this should
> > have the value of NAXIS1 * NAXIS2 if there is no gap between the binary
> > table and the data heap.
> 
> You are correct, this is an error.
> 
> 	- Doug
-- 
Pedro Osuna Alcalaya

 
Software Engineer
European Space Astronomy Centre
(ESAC/ESA)
e-mail: Pedro.Osuna@esa.int
Tel + 34 91 8131314
---------------------------------                                                                                
European Space Astronomy Centre
European Space Agency
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN

From owner-dm@eso.org  Tue Feb  1 18:03:03 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11H2h10007469
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 18:02:44 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11H2hi3007467
	for dm-outgoing; Tue, 1 Feb 2005 18:02:43 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11H2V10007437;
	Tue, 1 Feb 2005 18:02:31 +0100 (MET)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11H2ShA015387;
	Tue, 1 Feb 2005 18:02:29 +0100 (CET)
Received: from stsci.edu (obiwan.stsci.edu [130.167.236.123])
	by donner.stsci.edu (MOS 3.5.5-GR)
	with ESMTP id BGY04147;
	Tue, 1 Feb 2005 12:02:03 -0500 (EST)
Message-ID: <41FFB63F.44FEEF31@stsci.edu>
Date: Tue, 01 Feb 2005 12:02:55 -0500
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pedro Osuna <Pedro.Osuna@sciops.esa.int>
CC: dal@ivoa.net, dm@ivoa.net, Jesus.Salgado@sciops.esa.int,
        Christophe.Arviset@esa.int, Isa.Barbarisi@sciops.esa.int
Subject: Re: SED Data Model version 0.92
References: <Pine.LNX.4.44.0502010753480.15350-100000@lepus.tuc.noao.edu> <1107276726.26799.6892.camel@isol03.vilspa.esa.int>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Junkmail-Status: score=0/50, host=donner.stsci.edu
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.4
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Ivo Busko <busko@stsci.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Hi, all

So in light of this clarification, I'll rephrase
my former post to say that the files Specview is
generating are SED 0.9 - compliant; they are not
directly related to any SSAP service.

Thanks, Pedro!

Cheers,

-Ivo




Pedro Osuna wrote:
> 
> Dear all,
> 
> there might be some confusion on the naming of the different things.
> 
> The Simple Spectrum Access Protocol refers to the protocol to access the
> Spectra (as the SIAP does for images) whereas the SED Data Model
> describes how those spectra should be modeled (to be compatible with the
> IVOA specification).
> 
> The SSAP is not finished yet. There is only a version 0.1 document. We
> have asked for the inclusion of a couple of dimensional parameters in
> that protocol, and are already using it.
> 
> You can see a real service using SSAP registered data using our VOSpec
> tool at:
> 
> http://esavo.esa.int/vospec/
> 
> When inputing a target and clicking "Go", the tool will access the NVO
> Registry and get those services registered as giving SSAP access to
> their data.
> 
> Among those services is the SLOAN spectrum service. This service is the
> only one currently giving SED v0.9 compatible spectra (through an SSAP
> protocol).
> 
> Therefore, we do have already a tool that accesses Spectra using
> -current- SSAP and one of the services provides the Spectra in SED v0.9
> compatible form.
> 
> As you can see, there are other five services giving SSAP access (ISO,
> IUE, HST, FUSE, HyperLEDA) which do not -however- give their spectra in
> SED v0.9 compatible form.
> 
> I hope this clarifies the issue.
> 
> Cheers,
> P.
> 
> On Tue, 2005-02-01 at 16:20, Doug Tody wrote:
> > Hi Randy -
> >
> > Thanks for taking a look at this and providing some feedback.
> >
> > > I just  discovered the IVOA SED Data Model document version 0.92 and
> > > wanted to ask some questions about it. Since we have been anxiously
> > > awaiting an SSAP for distributing spectral data from MAST, we were happy
> > > to see progress being made.
> > >
> > > First of all, I am confused why the document has changed from the Simple
> > > Spectral Data Model to the SED Data Model when it will be used to
> > > "represent SED, spectra and time series data".  Do you plan to write
> > > separate documents for each data type?
> >
> > It is still called Simple Spectral Access and the "spectral data model"
> > is not restricted to SEDs.  SEDs, spectra, and time series are all
> > spectrophotometric (spectral) data.  Basically they are all sequences of
> > spectrophotometric data points, just organized in different ways.
> >
> > There is no intention to write a different document for each of these
> > types of data although we do expect that service instances will generally
> > support only one type.  Accessing 1D spectrum is probably the most common
> > use case and the whole interface should reduce to something fairly simple
> > for this case.  (Although every time we have this discussion people want
> > to add more features to the model).
> >
> > > Also, I am confused about the FITS serialization in section 8.1. Are
> > > you requiring variable-length arrays and not allowing array fields
> > > within the binary table itself?  I would think not all data sets require
> > > variable-length arrays and the FITS standard even recommends a simpler
> > > format when this feature is not necessary.
> >
> > Good point, the document does talk explicitly about variable length arrays
> > and that should probably be revisited.  Whether a fixed or variable array
> > is used should probably be left up to the data provider.  Fixed arrays
> > are preferred where they are sufficient.  The data model does not care,
> > it is purely a representation issue.
> >
> > > Finally, I think there are errors in the sample FITS header shown.
> > > It look like there are actually 15 fields, not 14 (there are 2 sets of
> > > TTYPE2 & TFORM2 keywords), and there is no THEAP keyword describing the
> > > offset to the data heap. Unless the convention has changed, this should
> > > have the value of NAXIS1 * NAXIS2 if there is no gap between the binary
> > > table and the data heap.
> >
> > You are correct, this is an error.
> >
> >       - Doug
> --
> Pedro Osuna Alcalaya
> 
> 
> Software Engineer
> European Space Astronomy Centre
> (ESAC/ESA)
> e-mail: Pedro.Osuna@esa.int
> Tel + 34 91 8131314
> ---------------------------------
> European Space Astronomy Centre
> European Space Agency
> P.O. Box 50727
> E-28080 Villafranca del Castillo
> MADRID - SPAIN

From owner-dal@eso.org  Tue Feb  1 18:58:28 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11Htt10013441
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 18:55:56 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11Httkk013440
	for dal-outgoing; Tue, 1 Feb 2005 18:55:55 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11Htp10013428
	for <dal@ivoa.net>; Tue, 1 Feb 2005 18:55:52 +0100 (MET)
Received: from milkyway.gsfc.nasa.gov (milkyway.gsfc.nasa.gov [128.183.16.143])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11HtmhA017076
	for <dal@ivoa.net>; Tue, 1 Feb 2005 18:55:50 +0100 (CET)
Received: from [128.183.17.125] (sysfits.gsfc.nasa.gov [128.183.17.125])
	by milkyway.gsfc.nasa.gov (8.13.1/8.13.1) with ESMTP id j11HtgvF001977;
	Tue, 1 Feb 2005 12:55:42 -0500
Message-ID: <41FFC29E.60009@nasa.gov>
Date: Tue, 01 Feb 2005 12:55:42 -0500
From: William Pence <William.D.Pence@nasa.gov>
Organization: HEASARC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041222
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Randall Thompson <rthomp@stsci.edu>
CC: dal@ivoa.net
Subject: Re: SED Data Model version 0.92
References: <41FF90E7.5010406@stsci.edu>
In-Reply-To: <41FF90E7.5010406@stsci.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-Scanned-By: MIMEDefang 2.49 on 128.183.16.143
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.4
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: William Pence <William.D.Pence@nasa.gov>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Randall Thompson wrote:
 >
>    Finally, I think there are errors in the sample FITS header shown. It 
> look like there are actually 15 fields, not 14 (there are 2 sets of TTYPE2 & 
> TFORM2 keywords), and there is no THEAP keyword describing the offset to 
> the data heap. Unless  the convention has
> changed, this should have the value of NAXIS1 * NAXIS2 if there is no 
> gap between the binary table and the data heap.

The THEAP keyword is optional and is assumed to have the value NAXIS1 * 
NAXIS2 if it is not present.  This is described in the appendix B.1 of the 
FITS Standard.

Bill Pence
-- 
____________________________________________________________________
Dr. William Pence                          William.D.Pence@nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)
Greenbelt MD 20771                         +1-301-286-1684 (fax)


From owner-apps@eso.org  Tue Feb  1 19:06:22 2005
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11I6B10014545
	for <apps-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 19:06:11 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11I6Bod014544
	for apps-outgoing; Tue, 1 Feb 2005 19:06:11 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11I6710014534;
	Tue, 1 Feb 2005 19:06:07 +0100 (MET)
Received: from skysrv.pha.jhu.edu (skysrv.pha.jhu.edu [128.220.233.32])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11I6357027842;
	Tue, 1 Feb 2005 19:06:03 +0100 (CET)
Received: from magnetar.pha.jhu.edu (magnetar.pha.jhu.edu [128.220.233.116])
	by skysrv.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id j11I5v811087;
	Tue, 1 Feb 2005 13:05:57 -0500
Received: from localhost (budavari@localhost)
	by magnetar.pha.jhu.edu (8.11.6/8.11.6) with ESMTP id j11I5v521363;
	Tue, 1 Feb 2005 13:05:57 -0500
X-Authentication-Warning: magnetar.pha.jhu.edu: budavari owned process doing -bs
Date: Tue, 1 Feb 2005 13:05:57 -0500 (EST)
From: Tamas Budavari <budavari@pha.jhu.edu>
To: Ivo Busko <busko@stsci.edu>
cc: dal@ivoa.net, <dm@ivoa.net>, <apps@ivoa.net>
Subject: Re: SSAP sample files
In-Reply-To: <41FFA630.C3886D33@stsci.edu>
Message-ID: <Pine.LNX.4.44.0502011127440.20912-100000@magnetar.pha.jhu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.4
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Tamas Budavari <budavari@pha.jhu.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


Hi Ivo -- Wow!!!

That's more than good news!  So you have not only implemented the SED
specifications independently from our spectrum services at Hopkins but
also integrated the access from http://voservices.net/spectrum into your
code on a different platform. Sounds like the proof of the pudding ;-)
(maybe should have sent it straight to interop)

Cheers, T.


On Tue, 1 Feb 2005, Ivo Busko wrote:

> Folks,
> 
> I am about to release a new version of Specview with
> the ability to write spectrograms in SSAP format. 
> 
> However, before I do that, I would greatly appreciate
> any comments, cristicisms and the like from the experts
> out there. 
> 
> I tried to follow the specs in the SED Data  Model v 0.92.
> I am sure there are things that are missing, misinterpreted 
> by me, or plainly wrong, in my implementation. Thus, before 
> releasing flawed code, it would be of great help to hear 
> what people have to say about the files created by Specview.
> 
> To that end, I put a few samples at
> 
> http://specview.stsci.edu/SSAP/
> 
> They include a multi-instrument SED, a few orders of a HST 
> STIS echelle spectrogram, two segments of an ISO-LWS spectrum,
> a comparison between data and a template (from the AVO demo),
> and a spectrum retrieved from the VOServices Web Services 
> interface at http://www.voservices.org/.
> 
> FITS serialization will be added in a future release.
> 
> Regards,
> 
> -Ivo
> 
>  *********************************************************************
>  *  Ivo C. Busko, PhD                        e-mail: busko@stsci.edu *
>  *  Senior Systems Software Engineer                                 *
>  *  Astronomy Tools and Applications                                 *
>  *  Engineering and Software Services Division  Voice: (410)338-4472 *
>  *  Space Telescope Science Institute             FAX: (410)338-4767 *
>  *  3700 San Martin Drive                                            *
>  *  Baltimore MD 21218-2410  USA                                     *
>  *********************************************************************
> 



From owner-dal@eso.org  Tue Feb  1 21:38:44 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11KcS10002215
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 1 Feb 2005 21:38:28 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j11KcSA7002214
	for dal-outgoing; Tue, 1 Feb 2005 21:38:28 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11KcP10002207
	for <dal@ivoa.net>; Tue, 1 Feb 2005 21:38:25 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j11KcNhA021317
	for <dal@ivoa.net>; Tue, 1 Feb 2005 21:38:23 +0100 (CET)
Received: from xebec.cfa.harvard.edu (xebec [131.142.52.100])
	by head.cfa.harvard.edu (d/w) with ESMTP id j11KcHRk006167
	for <dal@ivoa.net>; Tue, 1 Feb 2005 15:38:17 -0500 (EST)
From: Arnold Rots <arots@head.cfa.harvard.edu>
Received: (from arots@localhost)
	by xebec.cfa.harvard.edu (8.12.8p1/8.12.8) id j11KcGig019487
	for dal@ivoa.net; Tue, 1 Feb 2005 15:38:16 -0500 (EST)
Message-Id: <200502012038.j11KcGig019487@xebec.cfa.harvard.edu>
Subject: SED Data Model version 0.93
To: dal@ivoa.net
Date: Tue, 1 Feb 2005 15:38:16 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL99 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.5
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Arnold Rots <arots@head.cfa.harvard.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Just a few random comments on 0.93.

I would suggest to use BARYCENTER, rather than HELIOCENTER for defaults.

So, what do we do when the reference position is TOPOCENTER?
That renders the time information useless for certain applications,
lacking information on where the TOPOCENTER is exactly.

ISO 8601 cannot be prefixed with a minus sign.
We should stipulate that ISO8601 will always represent (extrapolated)
Gregorian dates, independent of date and location, but all values
prior to 0001-01-01 are undefined and need to be represented as JD -
as the next version of the STC WD will say.
I would suggest allowing absolute times in JD and MJD (i.e., without a
reference time) as well as reference times in JD and MJD.

  - Arnold

--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots@head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From owner-apps@eso.org  Wed Feb  2 12:00:10 2005
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12Axvlp001600
	for <apps-outgoing@mercury.hq.eso.org>; Wed, 2 Feb 2005 11:59:57 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j12AxvtH001599
	for apps-outgoing; Wed, 2 Feb 2005 11:59:57 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12Axrlp001590;
	Wed, 2 Feb 2005 11:59:53 +0100 (MET)
Received: from sol.star.bris.ac.uk (sol.star.bris.ac.uk [137.222.58.39])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12AxphA011847;
	Wed, 2 Feb 2005 11:59:51 +0100 (CET)
Received: from andromeda.star.bris.ac.uk ([137.222.58.155] ident=root)
	by sol.star.bris.ac.uk with esmtp (Exim 3.35 #1)
	id 1CwIEW-0000iD-00; Wed, 02 Feb 2005 10:59:40 +0000
Received: from mbt (helo=localhost)
	by andromeda.star.bris.ac.uk with local-esmtp (Exim 3.36 #1)
	id 1CwIEV-0007e7-00; Wed, 02 Feb 2005 10:59:39 +0000
Date: Wed, 2 Feb 2005 10:59:39 +0000 (GMT)
From: Mark Taylor <m.b.taylor@bristol.ac.uk>
X-X-Sender: mbt@andromeda.star.bris.ac.uk
To: Ivo Busko <busko@stsci.edu>
cc: dal@ivoa.net, <dm@ivoa.net>, <apps@ivoa.net>
Subject: Re: SSAP sample files
In-Reply-To: <41FFA630.C3886D33@stsci.edu>
Message-ID: <Pine.LNX.4.44.0502021009500.29235-100000@andromeda.star.bris.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.2.0
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Mark Taylor <m.b.taylor@bristol.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

On Tue, 1 Feb 2005, Ivo Busko wrote:

> Folks,
> 
> I am about to release a new version of Specview with
> the ability to write spectrograms in SSAP format. 
> 
> However, before I do that, I would greatly appreciate
> any comments, cristicisms and the like from the experts
> out there. 
> 
> I tried to follow the specs in the SED Data  Model v 0.92.
> I am sure there are things that are missing, misinterpreted 
> by me, or plainly wrong, in my implementation. Thus, before 
> releasing flawed code, it would be of great help to hear 
> what people have to say about the files created by Specview.
> 
> To that end, I put a few samples at
> 
> http://specview.stsci.edu/SSAP/
> 
> They include a multi-instrument SED, a few orders of a HST 
> STIS echelle spectrogram, two segments of an ISO-LWS spectrum,
> a comparison between data and a template (from the AVO demo),
> and a spectrum retrieved from the VOServices Web Services 
> interface at http://www.voservices.org/.

Ivo,

Validating these documents against the VOTable schema shows that
they have a number of errors - they are well-formed XML but not
valid VOTable documents.  The errors are in two categories:

  - Many FIELD and PARAM elements lack the required "datatype" attribute.
    Note that if you have string-valued PARAMs or FIELDs you should
    use the attributes:

       datatype="char" arraysize="*" 

    or similar (not just datatype="char" without an arraysize, 
    which means a single character!)

  - The values of ID attributes are controlled.  First, the value must 
    be an XML name.  Basically this means it must start with a letter
    or underscore and continue with alphanumerics, underscores, or
    '.', '-', ':'.  So pathnames are not a good choice.

    Furthermore, since the ID values identify a single element in the
    document, they must be unique.  In echelle.xml for instance, 
    several different (though obviously similar) FIELD elements have
    the declaration 'ID="Coord"' - this makes the XML invalid.

    Unless you are deliberately trying to identify a single element in
    the document, for instance to facilitate cross-referencing or
    an XPath query, it's usually safer to stick with the 'name' attribute.

I hadn't looked at the SED data model document up till now, but having
taken a quick look, I note that the missing datatype attribute problem is 
present throughout in the example VOTable serialization presented there,
so you can't really be blamed for this!  There are many other errors 
in this example too (it is not well-formed XML) - please can they 
be fixed!  I can advise if necessary.

In both cases, the errors are easy to spot if you run the VOTable
through an XML validator (checking against the VOTable schema)
Sun's Multi-Schema XML Validator
(http://www.sun.com/software/xml/developers/multischema/) is one tool
that can do this for you, though I'm sure there are others.  
You can check well-formedness (and possibly validate against the DTD,
though this is not normative at VOTable 1.1) using other tools such
as xmllint which comes with RedHat Linux.
Can I encourage people who are publishing VOTables in documentation 
or as data providers to do so!

Mark

-- 
Mark Taylor    Starlink Programmer     Physics,  Bristol University, UK
m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From owner-apps@eso.org  Wed Feb  2 14:35:33 2005
Return-Path: <owner-apps@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12DZLlp024825
	for <apps-outgoing@mercury.hq.eso.org>; Wed, 2 Feb 2005 14:35:22 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j12DZLkZ024824
	for apps-outgoing; Wed, 2 Feb 2005 14:35:21 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-apps@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12DYxlp024738;
	Wed, 2 Feb 2005 14:34:59 +0100 (MET)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12DYp57027118;
	Wed, 2 Feb 2005 14:34:52 +0100 (CET)
Received: from stsci.edu (obiwan.stsci.edu [130.167.236.123])
	by donner.stsci.edu (MOS 3.5.5-GR)
	with ESMTP id BHA18478;
	Wed, 2 Feb 2005 08:34:35 -0500 (EST)
Message-ID: <4200D71D.4BC473AF@stsci.edu>
Date: Wed, 02 Feb 2005 08:35:25 -0500
From: Ivo Busko <busko@stsci.edu>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Taylor <m.b.taylor@bristol.ac.uk>
CC: dal@ivoa.net, dm@ivoa.net, apps@ivoa.net
Subject: Re: SSAP sample files
References: <Pine.LNX.4.44.0502021009500.29235-100000@andromeda.star.bris.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Junkmail-Status: score=0/50, host=donner.stsci.edu
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.2.0
X-Virus-Scanned: by amavisd-new
Sender: owner-apps@eso.org
Precedence: bulk
Reply-To: Ivo Busko <busko@stsci.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi, Mark

Thanks for catching those errors. Yes, I didn't run the
files thru a XML validator; the only thing I did was to
make shure the "looked similar" to the example in the
SED data model document. My Java IDE also provides some
basic XML validation, and I used that as well. Not enough,
by all means...

I'll fix the errors and re-post the files. Thanks for 
the suggestion on XML validator tools.

Cheers,

-Ivo

> 
> On Tue, 1 Feb 2005, Ivo Busko wrote:
> Ivo,
> 
> Validating these documents against the VOTable schema shows that
> they have a number of errors - they are well-formed XML but not
> valid VOTable documents.  The errors are in two categories:
> 
>   - Many FIELD and PARAM elements lack the required "datatype" attribute.
>     Note that if you have string-valued PARAMs or FIELDs you should
>     use the attributes:
> 
>        datatype="char" arraysize="*"
> 
>     or similar (not just datatype="char" without an arraysize,
>     which means a single character!)
> 
>   - The values of ID attributes are controlled.  First, the value must
>     be an XML name.  Basically this means it must start with a letter
>     or underscore and continue with alphanumerics, underscores, or
>     '.', '-', ':'.  So pathnames are not a good choice.
> 
>     Furthermore, since the ID values identify a single element in the
>     document, they must be unique.  In echelle.xml for instance,
>     several different (though obviously similar) FIELD elements have
>     the declaration 'ID="Coord"' - this makes the XML invalid.
> 
>     Unless you are deliberately trying to identify a single element in
>     the document, for instance to facilitate cross-referencing or
>     an XPath query, it's usually safer to stick with the 'name' attribute.
> 
> I hadn't looked at the SED data model document up till now, but having
> taken a quick look, I note that the missing datatype attribute problem is
> present throughout in the example VOTable serialization presented there,
> so you can't really be blamed for this!  There are many other errors
> in this example too (it is not well-formed XML) - please can they
> be fixed!  I can advise if necessary.
> 
> In both cases, the errors are easy to spot if you run the VOTable
> through an XML validator (checking against the VOTable schema)
> Sun's Multi-Schema XML Validator
> (http://www.sun.com/software/xml/developers/multischema/) is one tool
> that can do this for you, though I'm sure there are others.
> You can check well-formedness (and possibly validate against the DTD,
> though this is not normative at VOTable 1.1) using other tools such
> as xmllint which comes with RedHat Linux.
> Can I encourage people who are publishing VOTables in documentation
> or as data providers to do so!
> 
> Mark
> 
> --
> Mark Taylor    Starlink Programmer     Physics,  Bristol University, UK
> m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From owner-dm@eso.org  Wed Feb  2 20:09:41 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12J9Nlp019551
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 2 Feb 2005 20:09:24 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j12J9NVj019550
	for dm-outgoing; Wed, 2 Feb 2005 20:09:23 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12J9Dlp019513;
	Wed, 2 Feb 2005 20:09:13 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12J9B57008529;
	Wed, 2 Feb 2005 20:09:12 +0100 (CET)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id j12J95Rk006918;
	Wed, 2 Feb 2005 14:09:05 -0500 (EST)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id j12J95kD029684;
	Wed, 2 Feb 2005 14:09:05 -0500 (EST)
Date: Wed, 2 Feb 2005 14:09:05 -0500 (EST)
Message-Id: <200502021909.j12J95kD029684@urania.cfa.harvard.edu>
To: dal@ivoa.net, dm@ivoa.net, rthomp@stsci.edu
Subject: SED Data Model version 0.92
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.2.9
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi SSAP colleagues,
 
A brief catchup - sorry for the lack of progress recently.
I'll be out of email contact until Feb 7 and then
hope to get stuck in to SSAP work.

Alberto's message of Jan 25:
I agree we need to develop the Characterization model; but
this will still take some work, and I want to deploy this
interim spectrum model without waiting for it.

Randy's request for progress on common FITS file formats
for spectra: absolutely. The SSAP model FITS serialization
is a first try at this.

>     We just had our HST coordination meeting with CADC (Daniel Durand)
> and  ST-ECF (Alberto Micol). There was interest in reformatting the existing
> FITS spectral files to a common format for our final HST archive. Assuming
> you have not yet decided on what will be required for the SSAP, do you have
> any suggestions?  There was speculation that we may need at least 2 
> formats;
> one for single order spectra and one for multi order echelle. However,
> if we adopt a binary table format with one row per spectral order, both 
> could
> be easily handled.  Any thoughts? Any progress on the SSAP?

The one-row-per-order format fits fairly well with our SSAP data model.
Each order would be considered a separate segment in our model; 
we should add some extra metadata to indicate they're from the same
observation.

Randy's technical questions on the model:


>     First of all, I am confused why the document has changed from the 
> Simple
> Spectral Data Model to the SED Data Model when it will be used to 
> "represent
> SED, spectra and time series data".  Do you plan to write separate 
> documents for
> each data type?

No, the idea is that spectra and time series are just special cases of
an SED, so we don't do anything different for them.

>     Also, I am confused about the FITS serialization in section 8.1. Are 
> you requiring
> variable-length arrays and not allowing array fields within the binary 
> table itself?
> I would think not all data sets require variable-length arrays and the 
> FITS standard even
> recommends a simpler format when this feature is not necessary.

Hmm. Hadn't though of this, but sure - I guess fixed length arrays
should also be an option. But general readers will have to handle
the variable length case.

>     Finally, I think there are errors in the sample FITS header shown. 

Sorry, I'll fix this too. I made some changes and didn't do it consistently.
I already made some fixes in a draft 0.93 that I've shared with
Tamas, but I'll try and bring that up to proper standard by next week
and post it to the group.

  - Jonathan McDowell

From owner-dal@eso.org  Wed Feb  2 20:11:00 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JAklp019884
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 2 Feb 2005 20:10:46 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j12JAkaD019883
	for dal-outgoing; Wed, 2 Feb 2005 20:10:46 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JAdlp019871;
	Wed, 2 Feb 2005 20:10:39 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JAbhA028690;
	Wed, 2 Feb 2005 20:10:37 +0100 (CET)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id j12JAVRk007075;
	Wed, 2 Feb 2005 14:10:31 -0500 (EST)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id j12JAVwf029692;
	Wed, 2 Feb 2005 14:10:31 -0500 (EST)
Date: Wed, 2 Feb 2005 14:10:31 -0500 (EST)
Message-Id: <200502021910.j12JAVwf029692@urania.cfa.harvard.edu>
To: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED Data Model: Questions and Comments
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.2.9
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Reply to Igor's message of Jan 21:

Technical:

1. Are the SIDIM parameters required? Right now they are optional
in the model, but required if you serialize in FITS. Their values
are implied by the required units and UCD, but Pedro would
like us to have them explicitly. Perhaps these parameters
should be moved in the model to the actual coordinate/flux fields
rather than be in the frame. I'll try and make a proposal on this
soon.

2. Missing FITS keywords for required DM fields.

Coverage.Location.Time.Value: I've added this as DATE-OBS (MJDOBS
would be another option).

Coverage.Extent.Sky: Added this as APERTURE

Coverage.Extent.Time: EXPOSURE  

Coverage.Location.Spectral, Coverage.Extent.Spectral: For the photometry
case it seems overkill to repeat these which are just the same as
the SpectralCoord values. Even for spectra, they are easily derivable
from the data. I'm inclined to make these optional after all.

3. This was an error for Coverage.Extent.Time, fixed now

4. Coverage.Location.Sky is an SEDCoord in the UML model
but a simple TextParam in the XML model. This was a (semi-)conscious
denormalization of the serialization for simplicity (in English:
the file format is simplified relative to the internal representation).


Ideology:

1. Continuum normalized fluxes.

Good suggestion, but it's a UCD rather than a unit issue.
These spectra are ratios of two flux spectra, therefore the
unit is 'dimensionless'. There is a ucd word arith.ratio; we can
propose a new ucd word spect.continuum and have
  ucd="arith.ratio;spect.continuum"

2. No flux calibration.

I'm still thinking about this one. In your case (shape right,
flux cal absent) one could just put a huge systematic error
bar on, but it would be better to have a special tag.

The harder case is when the shape is globally wrong. This
is also common: no division by instrument sensitivity, so
that the shape is locally right (you can see lines and measure
redshifts) but globally wrong. So we need
a 'counts spectrum' case too.

3. Atmosphere and vacuum wavelengths

As you note, we do support both in the document (with proposed
UCD em.wl.air). The problem for the DM group is:
what extra metadata do you need to let applications make the correction
from air to vacuum? Airmass, temperature, humidity, ...??

4. Resolution and line spread functions

Yes, I agree the line spread function needs to be in a future
version - but not in this version. The Resolution object will
need to be expanded, just as the Support object can be expanded
to Sensitivity.

However, I don't like your solution, because I think it
makes this special way of handling the Gauss-Hermite
resolution function. I think what we need to do is define
a standard VO way of defining parameterized functions
(maybe with XML type name VOFunction), and a way of 
declaring that the resolution is a function. It might
end up looking not so different from your solution, but
you wouldn't have a concept "ResolutionGH" - you'd
have a concept "ResolutionFunction" so 

<Resolution>
 <ResolutionFunction>
  <GHFunction>    (or: <Function name="Gauss-Hermite">
   <argument name="lambda" ucd="em.wl">
   <argument name="dlambda" ucd="em.wl,arith.diff">
   <param name="sigma" value="...">
   <param name="h3" value="...">
   <param name="h4" value="...">
  ....

The points here are that 
  (1) GHFunction can be reused in contexts other than Resolution
  (2) The format for a Function is always the same with name, <argument>.., <param>.., 
      so that you can do some base things on any function (like iterate on the parameters)
      and you don't have to design the object for every function you use.
  (3) We'll need some mechanism for keeping track of such defined functions,
      maybe with URIs to code to execute them. - how do we add a new function to the list?
  (4) It's explicit that the Resolution is being given as a function. In other
      words, if I have three resolutions:
          (a) Resolution with simple sigma
          (b) Resolution with GH function
          (c) Resolution with Lorentzian function
      we want it to be obvious that (b) and (c) are like each other but different from (a),
      and that isn't true in your approach.


(5) 2D and 3D multi object spectra (in private email to me)

Your proposal (table of spectra and table of positions for the spectra)
is OK for a multi-fiber system, but I don't think it's good for a real
data cube (integral field, or X-ray CCD) where the natural representation
is a true 3-dimensional pixel array. We can define both models
and a transformation between them. I'm not quite ready to handle this
until we have an implementation of SSAP on the floor
and working. (recall we have the format, but not the SSAP protocol
at this time).

 - Jonathan



From owner-dm@eso.org  Wed Feb  2 20:11:56 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JBglp020071
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 2 Feb 2005 20:11:42 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j12JBgsb020070
	for dm-outgoing; Wed, 2 Feb 2005 20:11:42 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JBclp020064;
	Wed, 2 Feb 2005 20:11:38 +0100 (MET)
Received: from head.cfa.harvard.edu (head.cfa.harvard.edu [131.142.41.8])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JBa57008605;
	Wed, 2 Feb 2005 20:11:37 +0100 (CET)
Received: from urania.cfa.harvard.edu (urania [131.142.52.147])
	by head.cfa.harvard.edu (d/w) with ESMTP id j12JBSRk007212;
	Wed, 2 Feb 2005 14:11:28 -0500 (EST)
From: Jonathan McDowell <jcm@head.cfa.harvard.edu>
Received: (from jcm@localhost)
	by urania.cfa.harvard.edu (8.12.8p1/8.12.8) id j12JBSVw029710;
	Wed, 2 Feb 2005 14:11:28 -0500 (EST)
Date: Wed, 2 Feb 2005 14:11:28 -0500 (EST)
Message-Id: <200502021911.j12JBSVw029710@urania.cfa.harvard.edu>
To: busko@stsci.edu, dal@ivoa.net, dm@ivoa.net, m.b.taylor@bristol.ac.uk
Subject: Re: SSAP sample files
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.1.9
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000



> On Tue, 1 Feb 2005, Ivo Busko wrote:
> 
> > Folks,
> > 
> > I am about to release a new version of Specview with
> > the ability to write spectrograms in SSAP format. 

Great news!


But, Mark writes...

> I hadn't looked at the SED data model document up till now, but having
> taken a quick look, I note that the missing datatype attribute problem is 
> present throughout in the example VOTable serialization presented there,
> so you can't really be blamed for this!  There are many other errors 
> in this example too (it is not well-formed XML) - please can they 
> be fixed!  I can advise if necessary.

Mea maxima culpa. I wrote it as an indication of the format, but
failed to validate it. I'm on travel for the next few days -
I'll iterate when I return but if you (Mark) would like to send me
a list of suggested changes I'll gladly add them. I have a few
other changes I plan to make anyway.

I'll review Ivo's files when I get back too.

- Jonathan

From owner-dal@eso.org  Wed Feb  2 20:47:32 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JlGlp025510
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 2 Feb 2005 20:47:17 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j12JlGIK025509
	for dal-outgoing; Wed, 2 Feb 2005 20:47:16 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JlDlp025494
	for <dal@ivoa.net>; Wed, 2 Feb 2005 20:47:13 +0100 (MET)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12JlA57009642
	for <dal@ivoa.net>; Wed, 2 Feb 2005 20:47:11 +0100 (CET)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id j12JkuMi008968;
	Wed, 2 Feb 2005 12:46:57 -0700
Date: Wed, 2 Feb 2005 12:46:54 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: dal@ivoa.net
Subject: Re: Merge lists
In-Reply-To: <200502021936.j12JakhA029520@apollo.hq.eso.org>
Message-ID: <Pine.LNX.4.44.0502021241560.12764-100000@lepus.tuc.noao.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.2.9
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

I don't think we need to do that.   What would be sensible would be, if
people send general announcements to several lists (DAL, DM, APPS in this
case) for followups to go to one of the lists.  If the topic is SSA,
including the SSA data model, this should go to DAL.  If the topic is
the Quantity data model it should go to DM (please!).  If the topic is
an application (Specview, VOSpec, whatever) followups should be to APPS.
And so forth.  The problem is people make general announcements and
the followup continues to go to all the lists.   Doug


On Wed, 2 Feb 2005, Tony Linde wrote:

> Would it be worth merging the DM and DAL lists since all messages seem to be
> duplicated between the two?
> 
> T.
> 
> __
> Tony Linde
> Phone:  +44 (0)116 223 1292    Mobile: +44 (0)7753 603356
> Fax:    +44 (0)116 252 3311    Email:  ael@star.le.ac.uk
> Post:   Department of Physics & Astronomy,
>         University of Leicester
>         Leicester, UK   LE1 7RH
> Web:    http://www.star.le.ac.uk/~ael
>             
> Project Manager, EuroVO VOTech   http://eurovotech.org 
> Programme Manager, AstroGrid     http://www.astrogrid.org 
> Co-Director,
>  Leicester e-Science Centre      http://www.e-science.le.ac.uk/ 

From owner-dm@eso.org  Wed Feb  2 23:13:58 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12MCElp013864
	for <dm-outgoing@mercury.hq.eso.org>; Wed, 2 Feb 2005 23:12:14 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j12MCEGf013863
	for dm-outgoing; Wed, 2 Feb 2005 23:12:14 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12MCAlp013853;
	Wed, 2 Feb 2005 23:12:10 +0100 (MET)
Received: from sn.sai.msu.ru (sn.sai.msu.ru [195.208.220.215])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j12MC8hA004976;
	Wed, 2 Feb 2005 23:12:08 +0100 (CET)
Received: from sn.sai.msu.ru (localhost [127.0.0.1])
	by sn.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j12MBYsm032578;
	Thu, 3 Feb 2005 01:11:34 +0300
Received: from localhost (chil@localhost)
	by sn.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j12MBYtx032575;
	Thu, 3 Feb 2005 01:11:34 +0300
X-Authentication-Warning: sn.sai.msu.ru: chil owned process doing -bs
Date: Thu, 3 Feb 2005 01:11:34 +0300 (MSK)
From: chil@sai.msu.su
X-X-Sender: chil@sn.sai.msu.ru
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED Data Model: Questions and Comments
In-Reply-To: <200502021910.j12JAVwf029692@urania.cfa.harvard.edu>
Message-ID: <Pine.LNX.4.58.0502030010350.29833@sn.sai.msu.ru>
References: <200502021910.j12JAVwf029692@urania.cfa.harvard.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.2.10
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: chil@sai.msu.su
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hello,

On Wed, 2 Feb 2005, Jonathan McDowell wrote:
> 2. No flux calibration.
> I'm still thinking about this one. In your case (shape right,
> flux cal absent) one could just put a huge systematic error
> bar on, but it would be better to have a special tag.

I don't think a huge systematic error bar is a good solution,
because somethimes even the order of magnitude is unknown.

The question connected to the flux calibration is handling "observed" fluxes
(FLUX-OBS in FITS) -- that are obtained with the ground-based observations,
and "physical" (FLUX-PHY) fluxes -- ones outside atmosphere. The correction
could be made in both directions if one has some extra metadata: meteo (temp.,
humidity, pressure, ...) and "obs. run-time"  (airmass, transparency or
extinction on a given wavelength, ...)

> 3. Atmosphere and vacuum wavelengths
> what extra metadata do you need to let applications make the correction
> from air to vacuum? Airmass, temperature, humidity, ...??

There is an IAU standard (!), that doesn't care of meteo params.
It tells (Morton 1991,ApJS,77,119) that
      AIR = VAC/(1.0 + 2.735182E-4 + 131.4182/VAC^2 +  2.76249E8/VAC^4)
where AIR and VAC are lambda-s in Angstroms. Should we follow it, or we should
implement something better (if exists)?

> 4. Resolution and line spread functions
> resolution function. I think what we need to do is define
> a standard VO way of defining parameterized functions
> (maybe with XML type name VOFunction), and a way of

It is a good idea! But this will require a standard way to access such
data, as you mentioned. What I can propose, is to define a kind of
"resource-discovery" approach. First step is to make a query to a
resource returning, say, a VOTable containing the function names, text
descriptions, and references to WSDL for accessing them. The second step is to
access these functions as normal WebServices. If we use this approach, it will
allow to handle tabulated functions as well. What DAL people think about it?

With best regards,
						Igor

From owner-dm@eso.org  Thu Feb  3 12:27:38 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j13BRQGr025384
	for <dm-outgoing@mercury.hq.eso.org>; Thu, 3 Feb 2005 12:27:26 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j13BRQ9c025383
	for dm-outgoing; Thu, 3 Feb 2005 12:27:26 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j13BRFGr025359;
	Thu, 3 Feb 2005 12:27:16 +0100 (MET)
Received: from amazone.ujf-grenoble.fr (amazone.ujf-grenoble.fr [193.54.238.254])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j13BRD57000533;
	Thu, 3 Feb 2005 12:27:14 +0100 (CET)
Received: from tibre1.ujf-grenoble.fr (tana1.ujf-grenoble.fr [152.77.18.74])
	by amazone.ujf-grenoble.fr (Switch-3.1.3/Switch-3.1.0/Configured  by JE 9 8 2004) with ESMTP id j13BR1Y1015913;
	Thu, 3 Feb 2005 12:27:02 +0100 (CET)
Received: from gagax1.obs.ujf-grenoble.fr (gagax1.obs.ujf-grenoble.fr [195.220.79.11])
	by tibre1.ujf-grenoble.fr (8.12.8p1/8.12.8) with ESMTP id j13BR7Cf032420;
	Thu, 3 Feb 2005 12:27:07 +0100 (CET)
	(envelope-from Gilles.Duvert@obs.ujf-grenoble.fr)
Received: from [193.54.238.142] (jmmc1.ujf-grenoble.fr [193.54.238.142])
	by gagax1.obs.ujf-grenoble.fr (AIX4.3/UCB 8.8.8/8.8.5) with ESMTP id MAA28186;
	Thu, 3 Feb 2005 12:27:01 +0100
Message-ID: <42020A85.9070203@obs.ujf-grenoble.fr>
Date: Thu, 03 Feb 2005 12:27:01 +0100
From: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan McDowell <jcm@head.cfa.harvard.edu>
CC: dal@ivoa.net, dm@ivoa.net
Subject: Re: SED Data Model: Questions and Comments
References: <200502021910.j12JAVwf029692@urania.cfa.harvard.edu>
In-Reply-To: <200502021910.j12JAVwf029692@urania.cfa.harvard.edu>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.3.0
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Gilles DUVERT <Gilles.Duvert@obs.ujf-grenoble.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi,

DM is not just the sum of its parts. One has to make choices. The need 
is to insure data QUALITY and MAINTAINABILITY. Keep things simple. DM 
should describe the physics of the data, that unite, not the habits of 
the data producer, that divide.

So:
Jonathan McDowell wrote:

>Reply to Igor's message of Jan 21:
>
>
>Ideology:
>
>2. No flux calibration.
>
>I'm still thinking about this one. In your case (shape right,
>flux cal absent) one could just put a huge systematic error
>bar on, but it would be better to have a special tag.
>
>The harder case is when the shape is globally wrong. This
>is also common: no division by instrument sensitivity, so
>that the shape is locally right (you can see lines and measure
>redshifts) but globally wrong. So we need
>a 'counts spectrum' case too.
>  
>
A measure is a value and an error. If there is no flux calibration, the 
measurement does not exist, and a data model shall not be concerned by this.
DO NOT PERMIT TO WRONG OR UNRELIABLE DATA TO BE OUT IN THE VO!!!

>3. Atmosphere and vacuum wavelengths
>
>As you note, we do support both in the document (with proposed
>UCD em.wl.air). The problem for the DM group is:
>what extra metadata do you need to let applications make the correction
>from air to vacuum? Airmass, temperature, humidity, ...??
>  
>
USE FREQUENCY, this is the core of reality, insensitive to media. Does a 
bracket gamma line takes a cold because the weather that day was cold 
and humid and it did not take its scarf? Leave the gory details to the 
producer of the data. Leave the end-user convert metadata frequencies to 
whatever unit it pleases himself.

>4. Resolution and line spread functions
>
>Yes, I agree the line spread function needs to be in a future
>version - but not in this version. The Resolution object will
>need to be expanded, just as the Support object can be expanded
>to Sensitivity.
>
>However, I don't like your solution, because I think it
>makes this special way of handling the Gauss-Hermite
>resolution function. I think what we need to do is define
>a standard VO way of defining parameterized functions
>(maybe with XML type name VOFunction), and a way of 
>declaring that the resolution is a function. It might
>end up looking not so different from your solution, but
>you wouldn't have a concept "ResolutionGH" - you'd
>have a concept "ResolutionFunction" so 
>
><Resolution>
> <ResolutionFunction>
>  <GHFunction>    (or: <Function name="Gauss-Hermite">
>   <argument name="lambda" ucd="em.wl">
>   <argument name="dlambda" ucd="em.wl,arith.diff">
>   <param name="sigma" value="...">
>   <param name="h3" value="...">
>   <param name="h4" value="...">
>  ....
>
>The points here are that 
>  (1) GHFunction can be reused in contexts other than Resolution
>  (2) The format for a Function is always the same with name, <argument>.., <param>.., 
>      so that you can do some base things on any function (like iterate on the parameters)
>      and you don't have to design the object for every function you use.
>  (3) We'll need some mechanism for keeping track of such defined functions,
>      maybe with URIs to code to execute them. - how do we add a new function to the list?
>  (4) It's explicit that the Resolution is being given as a function. In other
>      words, if I have three resolutions:
>          (a) Resolution with simple sigma
>          (b) Resolution with GH function
>          (c) Resolution with Lorentzian function
>      we want it to be obvious that (b) and (c) are like each other but different from (a),
>      and that isn't true in your approach.
>
>
>  
>
Let the DM support standard functions (sigma, gauss, lorentz) that fit 
99% of needs, and leave the transform of the data to this functions to 
the  expertize of the data producer. He knows best.

>(5) 2D and 3D multi object spectra (in private email to me)
>
>Your proposal (table of spectra and table of positions for the spectra)
>is OK for a multi-fiber system, but I don't think it's good for a real
>data cube (integral field, or X-ray CCD) where the natural representation
>is a true 3-dimensional pixel array. We can define both models
>and a transformation between them. I'm not quite ready to handle this
>until we have an implementation of SSAP on the floor
>and working. (recall we have the format, but not the SSAP protocol
>at this time).
>  
>
first case (table of spectra and table of positions for the spectra) is 
just a table with spectra, since a spectrum is more than often the 
spectrum of something that has a location-> done.

2nd case is really a data cube. Add polarisation that makes 4 
dimensions, if I do not count the fact that a measure is a (value,error) 
doublet and that 'spectrum' can be a complex . This is already supported 
by FITS standards and seems to please everybody (?). Should have a DM of 
its own, that sums up, e.g., Transforms(WCS), Spectra, Images...

> - Jonathan
>  
>

-- 
----------------------------------------------------------------------------
Gilles DUVERT, Astronome        | Gilles.Duvert@obs.ujf-grenoble.fr
Laboratoire d'Astrophysique     | Phone: +33 (0)4 76.51.48.85
Observatoire de Grenoble        | Fax:   +33 (0)4.76.44.88.21
BP 53X  F-38041 GRENOBLE CEDEX  | LAOG (http://www-laog.obs.ujf-grenoble.fr)
Dir. Technique JMMC(http://mariotti.ujf-grenoble.fr) Resp. Informatique LAOG
----------------------------------------------------------------------------


From owner-dm@eso.org  Mon Feb 14 01:14:57 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1E0Edit016986
	for <dm-outgoing@mercury.hq.eso.org>; Mon, 14 Feb 2005 01:14:39 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1E0EdFo016984
	for dm-outgoing; Mon, 14 Feb 2005 01:14:39 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1E0EVit016931;
	Mon, 14 Feb 2005 01:14:31 +0100 (MET)
Received: from sn.sai.msu.ru (sn.sai.msu.ru [195.208.220.215])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1E0EU57022473;
	Mon, 14 Feb 2005 01:14:30 +0100 (CET)
Received: from sn.sai.msu.ru (localhost [127.0.0.1])
	by sn.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j1E0EOsm000756;
	Mon, 14 Feb 2005 03:14:24 +0300
Received: from localhost (chil@localhost)
	by sn.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j1E0ENTt000753;
	Mon, 14 Feb 2005 03:14:24 +0300
X-Authentication-Warning: sn.sai.msu.ru: chil owned process doing -bs
Date: Mon, 14 Feb 2005 03:14:23 +0300 (MSK)
From: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-X-Sender: chil@sn.sai.msu.ru
To: dm@ivoa.net, dal@ivoa.net, Giovanni Covone <giovanni.covone@oamp.fr>,
        Philippe Prugniel <prugniel@obs.univ-lyon1.fr>
Subject: towards 3D data model
Message-ID: <Pine.LNX.4.58.0502140306581.7123@sn.sai.msu.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.13.16
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Dear all,

Taking into account the growing interest in the astronomical community to
the 3D spectroscopy methods, we propose to organize an "interest group", or
subgroup of the IVOA DM group (TBD), uniting people interested
in any kind of 3D technics (integral-field spectroscopy, scanning Fabry-Perot
imagery, multi-object spectroscopy, high-energy spatially and spectrally
resolved data (X-ray CCD), 3D radio data) and in the data modeling. The main
purpose of the group will be to define a general and abstract description of
the 3D datasets in the VO (3D data model). For a moment there are some
developments made by the Euro3D consortium concerning the data format for
multi-object spectroscopy, and integral-field spectroscopy. The starting
point for the 3D data model might exploit these ideas and basic concepts
of the SED Data Model at its present status.

3 of us are involved in the research dealing with 3D data, and we are
looking now for a collaboration in the VO community, and particularly in
DM and DAL IVOA working groups to promote the 3D techics.

If there are people interested, we would propose to arrange a discussion
about it during Kyoto Interop (maybe in a frame of DM or DAL sessions: TBD).


Best regards,
				Igor Chilingarian (SAI MSU; Obs.de Lyon)
				Philippe Prugniel (Obs.de Lyon; Obs.de Paris)
				Giovanni Covone   (Euro3D, Obs.de Marseille)

From owner-dal@eso.org  Mon Feb 14 05:44:41 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1E4iOit006097
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 14 Feb 2005 05:44:24 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1E4iOhO006096
	for dal-outgoing; Mon, 14 Feb 2005 05:44:24 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1E4iKit006090
	for <dal@ivoa.net>; Mon, 14 Feb 2005 05:44:20 +0100 (MET)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1E4iH57028675
	for <dal@ivoa.net>; Mon, 14 Feb 2005 05:44:18 +0100 (CET)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id j1E4i00G014823;
	Sun, 13 Feb 2005 21:44:01 -0700
Date: Sun, 13 Feb 2005 21:44:00 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
cc: dal@ivoa.net, Giovanni Covone <giovanni.covone@oamp.fr>,
        Philippe Prugniel <prugniel@obs.univ-lyon1.fr>
Subject: Re: towards 3D data model
In-Reply-To: <Pine.LNX.4.58.0502140306581.7123@sn.sai.msu.ru>
Message-ID: <Pine.LNX.4.61.0502132136300.7099@lepus.tuc.noao.edu>
References: <Pine.LNX.4.58.0502140306581.7123@sn.sai.msu.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: by amavisd-new
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.13.19
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Hi Igor -

It would be good to start looking at this.  Extending the image model
to 3D for spectral data cubes, IFU spectra etc. is something we should
tackle once SSA and the next version of SIA are done.  This will require
more data model work, and probably a new DAL interface to support cutting
subsets from large spectra data cubes at access time.

 	- Doug


On Mon, 14 Feb 2005, Igor Chilingarian wrote:

> Dear all,
>
> Taking into account the growing interest in the astronomical community to
> the 3D spectroscopy methods, we propose to organize an "interest group", or
> subgroup of the IVOA DM group (TBD), uniting people interested
> in any kind of 3D technics (integral-field spectroscopy, scanning Fabry-Perot
> imagery, multi-object spectroscopy, high-energy spatially and spectrally
> resolved data (X-ray CCD), 3D radio data) and in the data modeling. The main
> purpose of the group will be to define a general and abstract description of
> the 3D datasets in the VO (3D data model). For a moment there are some
> developments made by the Euro3D consortium concerning the data format for
> multi-object spectroscopy, and integral-field spectroscopy. The starting
> point for the 3D data model might exploit these ideas and basic concepts
> of the SED Data Model at its present status.
>
> 3 of us are involved in the research dealing with 3D data, and we are
> looking now for a collaboration in the VO community, and particularly in
> DM and DAL IVOA working groups to promote the 3D techics.
>
> If there are people interested, we would propose to arrange a discussion
> about it during Kyoto Interop (maybe in a frame of DM or DAL sessions: TBD).
>
>
> Best regards,
> 				Igor Chilingarian (SAI MSU; Obs.de Lyon)
> 				Philippe Prugniel (Obs.de Lyon; Obs.de Paris)
> 				Giovanni Covone   (Euro3D, Obs.de Marseille)
>
>

From owner-dm@eso.org  Mon Feb 14 19:03:51 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EI3VoK004778
	for <dm-outgoing@mercury.hq.eso.org>; Mon, 14 Feb 2005 19:03:31 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1EI3VdQ004777
	for dm-outgoing; Mon, 14 Feb 2005 19:03:31 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EI3RoK004773;
	Mon, 14 Feb 2005 19:03:27 +0100 (MET)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EI3Q57022226;
	Mon, 14 Feb 2005 19:03:26 +0100 (CET)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.4) with ESMTP id j1EI3KXd062943
          ; Mon, 14 Feb 2005 19:03:20 +0100 (CET)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id SAA08672;
	Mon, 14 Feb 2005 18:54:17 +0100 (MET)
Date: Mon, 14 Feb 2005 18:54:17 +0100 (MET)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200502141754.SAA08672@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net, giovanni.covone@oamp.fr,
        igor.chilingarian@obs.univ-lyon1.fr, prugniel@obs.univ-lyon1.fr
Subject: Re: towards 3D data model
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [130.79.200.1]); Mon, 14 Feb 2005 19:03:21 +0100 (CET)
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.14.9
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

dear Giovanni, Phillipe and Igor,
   I am happy that Euro 3D people will join the IVOA data model effort
This connection was missing since a long time. I am not personnaly sure
that creating a specific 3D data model is the best we can do to achieve
that. There is an ongoing "Characterization" data model effort supposed
to deal with any kind of observations and data sets.  (material can be found
on the list about that, and Giovanni, you can remember we discussed this last 
October). A subgroup is supposed to produce a draft long before Kyoto for 
discussion.
My immediate proposal is that somebody among Euro3D people can join the 
subgroup  and judge the pertinance of the ongoing work from the 3D point
of view.
  Your opinion about that ?
Cheers 
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Mon Feb 14 19:24:10 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EINeoK007100
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 14 Feb 2005 19:23:40 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1EINe1L007098
	for dal-outgoing; Mon, 14 Feb 2005 19:23:40 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EINWoK007063;
	Mon, 14 Feb 2005 19:23:32 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EINThA005601;
	Mon, 14 Feb 2005 19:23:30 +0100 (CET)
Received: from dropbox.aoc.nrao.edu (dropbox [146.88.1.13])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id j1EIN6F32010;
	Mon, 14 Feb 2005 11:23:06 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by dropbox.aoc.nrao.edu (8.12.8/8.12.8/smtp-gateway) with ESMTP id j1EIN6wk018591;
	Mon, 14 Feb 2005 11:23:06 -0700
Date: Mon, 14 Feb 2005 11:23:06 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
cc: dal@ivoa.net, <dm@ivoa.net>, <giovanni.covone@oamp.fr>,
        <igor.chilingarian@obs.univ-lyon1.fr>, <prugniel@obs.univ-lyon1.fr>
Subject: Re: towards 3D data model
In-Reply-To: <200502141754.SAA08672@alinda.u-strasbg.fr>
Message-ID: <Pine.LNX.4.44.0502141109260.5700-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7,
	BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37,
	QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.14.10
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Francois -

The characterization data model (also other general dataset data models 
such as identification etc.) apply to all datasets hence would apply to
3D data as well.

For modeling 3D data in DAL, more is required as we need to model the
actual dataset.  Currently we have 2D sky images (SIA) and various kinds of
tabular spectrophotometric data (SSA).  My feeling is that what is required
for spectral datacubes is a generalization of the 2D image model to 3D.
This would build upon the spectrophotometric metadata developed for SSA to
describe the observable, plus FITS WCS to describe the coordinate system.

This is probably what is needed for regularly gridded data such as a
spectral data cube.  It is also possible that for some data of this sort,
e.g., MOS or IFU data where the spectra have already been extracted, that
we should use the SSA data model instead.  It would be easy to extend
this to collections of spectra, which is what one has in this case.

It is possible that to support spectral data cubes we should just
fold the support into a future version of SIA - whether or not this is
advisable depends upon how much it complicates things.  It may be that
the complications would justify a new data access interface for 3D data.
In particular, we don't know at this point what is required to cutout
regions of a large spectral data cube.  We need to understand the science
drivers better to analyze this, i.e., what sorts of analysis do we want
to target with this capability.

	- Doug


On Mon, 14 Feb 2005, Francois Bonnarel wrote:

> dear Giovanni, Phillipe and Igor,
>    I am happy that Euro 3D people will join the IVOA data model effort
> This connection was missing since a long time. I am not personnaly sure
> that creating a specific 3D data model is the best we can do to achieve
> that. There is an ongoing "Characterization" data model effort supposed
> to deal with any kind of observations and data sets.  (material can be found
> on the list about that, and Giovanni, you can remember we discussed this last 
> October). A subgroup is supposed to produce a draft long before Kyoto for 
> discussion.
> My immediate proposal is that somebody among Euro3D people can join the 
> subgroup  and judge the pertinance of the ongoing work from the 3D point
> of view.
>   Your opinion about that ?
> Cheers 
> François
> 
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
> 
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
> ---------------------------------------------------------------------

From owner-dal@eso.org  Mon Feb 14 22:20:47 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ELK7oK026216
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 14 Feb 2005 22:20:07 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1ELK73t026215
	for dal-outgoing; Mon, 14 Feb 2005 22:20:07 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ELJxoK026175;
	Mon, 14 Feb 2005 22:19:59 +0100 (MET)
Received: from mesiob.obspm.fr (mesiob.obspm.fr [145.238.2.2])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ELJvhA009284;
	Mon, 14 Feb 2005 22:19:57 +0100 (CET)
Received: from [145.238.16.214] (pc-prugniel.obspm.fr [145.238.16.214])
	by mesiob.obspm.fr (8.12.3/8.12.3/SIO Observatoire de Paris - 01/01/03) with ESMTP id j1ELJpPw022744;
	Mon, 14 Feb 2005 22:19:51 +0100
Message-ID: <421115F7.5000708@obs.univ-lyon1.fr>
Date: Mon, 14 Feb 2005 22:19:51 +0100
From: Philippe Prugniel <prugniel@obs.univ-lyon1.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Doug Tody <dtody@nrao.edu>
CC: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>, dal@ivoa.net,
        dm@ivoa.net, giovanni.covone@oamp.fr
Subject: Re: towards 3D data model
References: <Pine.LNX.4.44.0502141109260.5700-100000@oak>
In-Reply-To: <Pine.LNX.4.44.0502141109260.5700-100000@oak>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (mesiob.obspm.fr [145.238.2.2]); Mon, 14 Feb 2005 22:19:51 +0100 (CET)
X-Virus-Scanned: by amavisd-new
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.14.12
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Philippe Prugniel <prugniel@obs.univ-lyon1.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Doug Tody wrote:

>For modeling 3D data in DAL, more is required as we need to model the
>actual dataset.  Currently we have 2D sky images (SIA) and various kinds of
>tabular spectrophotometric data (SSA).  My feeling is that what is required
>for spectral datacubes is a generalization of the 2D image model to 3D.
>This would build upon the spectrophotometric metadata developed for SSA to
>describe the observable, plus FITS WCS to describe the coordinate system.
>  
>

All 3D data cannot be easily formatted as regularly sampled data. There 
are several particular
cases and the most general model would be to represent them as 
collections of SED
(except for representing multicolor images with a slightly different WCS 
in each image).

Of course it would be good to be able to use a spatial WCS when it is 
possible, and a
spectral WCS when possible also.

>We need to understand the science
>drivers better to analyze this, i.e., what sorts of analysis do we want
>to target with this capability.
>  
>
I think it is the right way to proceed.
First define science cases and the type of data we want to handle. And try
to keep as simple as possible.

>>dear Giovanni, Phillipe and Igor,
>>   I am happy that Euro 3D people will join the IVOA data model effort
>>This connection was missing since a long time. I am not personnaly sure
>>    
>>
Just a precision: Neither myself or Igor belong to Euro 3D (we are 3D 
users), so I am not sure
yet how far you should consider that the E3D people join the IVOA DM 
effort; I hope they
will...

Sincerely. Philippe.

From owner-dal@eso.org  Mon Feb 14 22:55:44 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ELtToK000076
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 14 Feb 2005 22:55:29 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1ELtTHm000075
	for dal-outgoing; Mon, 14 Feb 2005 22:55:29 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ELtJoK000064;
	Mon, 14 Feb 2005 22:55:20 +0100 (MET)
Received: from sn.sai.msu.ru (sn.sai.msu.ru [195.208.220.215])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ELtIhA011196;
	Mon, 14 Feb 2005 22:55:18 +0100 (CET)
Received: from sn.sai.msu.ru (localhost [127.0.0.1])
	by sn.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j1ELtCsm010387;
	Tue, 15 Feb 2005 00:55:12 +0300
Received: from localhost (chil@localhost)
	by sn.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j1ELtCFu010384;
	Tue, 15 Feb 2005 00:55:12 +0300
X-Authentication-Warning: sn.sai.msu.ru: chil owned process doing -bs
Date: Tue, 15 Feb 2005 00:55:12 +0300 (MSK)
From: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-X-Sender: chil@sn.sai.msu.ru
To: Philippe Prugniel <prugniel@obs.univ-lyon1.fr>
cc: Doug Tody <dtody@nrao.edu>, dal@ivoa.net, dm@ivoa.net,
        giovanni.covone@oamp.fr
Subject: a science case for 3D data model
In-Reply-To: <421115F7.5000708@obs.univ-lyon1.fr>
Message-ID: <Pine.LNX.4.58.0502150038540.7123@sn.sai.msu.ru>
References: <Pine.LNX.4.44.0502141109260.5700-100000@oak>
 <421115F7.5000708@obs.univ-lyon1.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.14.13
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hello,

On Mon, 14 Feb 2005, Philippe Prugniel wrote:

> >We need to understand the science
> >drivers better to analyze this, i.e., what sorts of analysis do we want
> >to target with this capability.
> >
> >
> I think it is the right way to proceed.
> First define science cases and the type of data we want to handle. And try
> to keep as simple as possible.

The science case that we are working on now is the studies of the stellar
population history in the nearby galaxies. Technically it is the extraction of
kinematics and stellar population information from the absorbtion line
spectra. The required things for us are: relative flux calibration (we don't
care of the absolute fluxes, but about the correct "shape" of the spectra),
and precise description of the spectral resolution (line-spread function) and
its variations over spectral and spatial dimensions.

With best regards,
						Igor

From owner-dal@eso.org  Mon Feb 14 23:24:54 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EMOXoK005546
	for <dal-outgoing@mercury.hq.eso.org>; Mon, 14 Feb 2005 23:24:33 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1EMOXN0005545
	for dal-outgoing; Mon, 14 Feb 2005 23:24:33 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EMOToK005535
	for <dal@ivoa.net>; Mon, 14 Feb 2005 23:24:29 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EMOQhA011838
	for <dal@ivoa.net>; Mon, 14 Feb 2005 23:24:27 +0100 (CET)
Received: from dropbox.aoc.nrao.edu (dropbox [146.88.1.13])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id j1EMO7F22248;
	Mon, 14 Feb 2005 15:24:07 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by dropbox.aoc.nrao.edu (8.12.8/8.12.8/smtp-gateway) with ESMTP id j1EMO6wk006264;
	Mon, 14 Feb 2005 15:24:06 -0700
Date: Mon, 14 Feb 2005 15:24:06 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
cc: Philippe Prugniel <prugniel@obs.univ-lyon1.fr>, <dal@ivoa.net>,
        <giovanni.covone@oamp.fr>
Subject: Re: a science case for 3D data model
In-Reply-To: <Pine.LNX.4.58.0502150038540.7123@sn.sai.msu.ru>
Message-ID: <Pine.LNX.4.44.0502141520230.5700-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-6.7, required 7,
	BAYES_01 -5.40, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.37,
	QUOTED_EMAIL_TEXT -0.38, REPLY_WITH_QUOTES 0.00,
	USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.14.13
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Igor - What does this have to do with 3D data?  This sounds like something
which could be done using 1D spectra, possibly extracted from MOS or IFU
observations.  - Doug


On Tue, 15 Feb 2005, Igor Chilingarian wrote:
> Hello,
> 
> On Mon, 14 Feb 2005, Philippe Prugniel wrote:
> 
> > >We need to understand the science
> > >drivers better to analyze this, i.e., what sorts of analysis do we want
> > >to target with this capability.
> > >
> > >
> > I think it is the right way to proceed.
> > First define science cases and the type of data we want to handle. And try
> > to keep as simple as possible.
> 
> The science case that we are working on now is the studies of the stellar
> population history in the nearby galaxies. Technically it is the extraction of
> kinematics and stellar population information from the absorbtion line
> spectra. The required things for us are: relative flux calibration (we don't
> care of the absolute fluxes, but about the correct "shape" of the spectra),
> and precise description of the spectral resolution (line-spread function) and
> its variations over spectral and spatial dimensions.
> 
> With best regards,
> 						Igor
> 
> 

From owner-dal@eso.org  Tue Feb 15 00:09:09 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EN8s0d009173
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 00:08:54 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1EN8sge009172
	for dal-outgoing; Tue, 15 Feb 2005 00:08:54 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EN8o0d009163
	for <dal@ivoa.net>; Tue, 15 Feb 2005 00:08:50 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1EN8l57029976
	for <dal@ivoa.net>; Tue, 15 Feb 2005 00:08:48 +0100 (CET)
Received: from dropbox.aoc.nrao.edu (dropbox [146.88.1.13])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id j1EN8bF00574
	for <dal@ivoa.net>; Mon, 14 Feb 2005 16:08:37 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by dropbox.aoc.nrao.edu (8.12.8/8.12.8/smtp-gateway) with ESMTP id j1EN8awk010194;
	Mon, 14 Feb 2005 16:08:37 -0700
Date: Mon, 14 Feb 2005 16:08:36 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: dal@ivoa.net
Subject: Kyoto topics for DAL WG
Message-ID: <Pine.LNX.4.44.0502141604090.5700-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.4, required 7,
	BAYES_01 -5.40, USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.14.14
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hi DAL Folks -

To help plan the DAL sessions for the upcoming Kyoto meeting, please
send me any suggestions you would like to make for 1) topics to be 
discussed, or 2) presentations you would like to give.  I need this 
by sometime next week.  Thanks.

	- Doug

From owner-dal@eso.org  Tue Feb 15 01:43:46 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1F0h60d015365
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 01:43:06 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1F0h6lC015364
	for dal-outgoing; Tue, 15 Feb 2005 01:43:06 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1F0h20d015359
	for <dal@ivoa.net>; Tue, 15 Feb 2005 01:43:02 +0100 (MET)
Received: from sn.sai.msu.ru (sn.sai.msu.ru [195.208.220.215])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1F0h0hA015062
	for <dal@ivoa.net>; Tue, 15 Feb 2005 01:43:01 +0100 (CET)
Received: from sn.sai.msu.ru (localhost [127.0.0.1])
	by sn.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j1F0gssm011962;
	Tue, 15 Feb 2005 03:42:54 +0300
Received: from localhost (chil@localhost)
	by sn.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j1F0gsX7011959;
	Tue, 15 Feb 2005 03:42:54 +0300
X-Authentication-Warning: sn.sai.msu.ru: chil owned process doing -bs
Date: Tue, 15 Feb 2005 03:42:54 +0300 (MSK)
From: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-X-Sender: chil@sn.sai.msu.ru
To: Doug Tody <dtody@nrao.edu>
cc: Philippe Prugniel <prugniel@obs.univ-lyon1.fr>, dal@ivoa.net,
        giovanni.covone@oamp.fr
Subject: Re: a science case for 3D data model
In-Reply-To: <Pine.LNX.4.44.0502141520230.5700-100000@oak>
Message-ID: <Pine.LNX.4.58.0502150321430.7123@sn.sai.msu.ru>
References: <Pine.LNX.4.44.0502141520230.5700-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.14.16
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Doug,

Sorry, I wasn't clear enough. Our goal is to study the connection between
features in the spatial distribution of stellar population properties:
age/metallicity gradients, distinct cores, etc.; and kinematical features in
velocity fields: discs, 3D dynamical structures, etc; and possibly also with
features in brightness/color maps.

One of the advantages of IFU over long-slit is that you will probably
not miss the kinematical major/minor axes, that may happen for long-slit
observations of early-type galaxies. We study diffuse (dwarf) ellipticals
and sometimes such problems occur.

On Mon, 14 Feb 2005, Doug Tody wrote:

> Igor - What does this have to do with 3D data?  This sounds like something
> which could be done using 1D spectra, possibly extracted from MOS or IFU
> observations.  - Doug
>
One more point: this science case can't be done in the VO right now with the
present Spectral Data Model 0.93beta even for 1D data because we can't
describe the spectral resolution and its variations over the spectral
coordinate properly.

With best regards,
						Igor

From owner-dm@eso.org  Tue Feb 15 11:09:06 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FA8o0d012683
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 11:08:50 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1FA8okt012682
	for dm-outgoing; Tue, 15 Feb 2005 11:08:50 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FA8k0d012677;
	Tue, 15 Feb 2005 11:08:47 +0100 (MET)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FA8jhA002656;
	Tue, 15 Feb 2005 11:08:45 +0100 (CET)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.5pre1) with ESMTP id j1FA8dqn020386
          ; Tue, 15 Feb 2005 11:08:39 +0100 (CET)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id KAA13600;
	Tue, 15 Feb 2005 10:59:35 +0100 (MET)
Date: Tue, 15 Feb 2005 10:59:35 +0100 (MET)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200502150959.KAA13600@alinda.u-strasbg.fr>
To: dal@ivoa.net, dm@ivoa.net
Subject: 3D data model
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [130.79.200.1]); Tue, 15 Feb 2005 11:08:40 +0100 (CET)
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.15.1
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Doug, Igor, Philippe, Giovanni,
   Sorry to have given you maybe the impression to be a little bit "chilly".
I basically agree with what you say, Doug.
   My main concern was about keeping a consistency in the work of the DM
group. If "Characterization" is to be seen as some sort of federator DM
for Observations and Datasets, we absolutly need that newcomers from the IFU
community to have a look to the work done in Characterization.
   So , definitly I am really happy that we discuss these topics in the group
before and in Kyoto, and we get specialists (were they Euro3D consortiums
participants or not) coming in for that.

    What I am only reluctant to  is to create a  new DM Subgroup each time
a new point of view is coming in.
    Just to recall we allready have the following subgroups (or specific
data models efforts) in the DM Working group:
    Quantity
    STC
    SED/spectrum
    Characterization (and previously Observation)
    And since a couple of monthes: Catalog.
In addition  the "Radio" effort was always done in close connection to
Observation Characterization, as a kind of specialisation of it.
    The SED/spectrum was considered to be urgent enough to be separated
from a more general and slower effort on Characterization/Observation .
     I am just afraid that adding new subgroups will make the whole
Working group unmanageable and I would really like to have Jonathan's
advice about that.
     Do we really need a new one , or can we have the 3D input in the
existing ones (basically SED/pectrum and Characterization?)

   Cheers
François

PS: Euro3D is an European effort to federate IFU and other 3D spectroscopy
communities. Among other things they defined a new FITS format for 3D data
and they were really missing in the IVOA discussion. So I think it's really
good news, if Giovanni and others can participate.
 See http://www.aip.de/Euro3D/


  In addition  the "Radio" effort was always done in close connection to
Observation Characterization, as a kind of specialisation of it.
    The SED/spectrum was considered to be urgent enough to be separated
from a more general and slower effort on Characterization/Observation .
     I am just afraid that adding new subgroups will make the whole
Working group unmanageable and I would really like to have Jonathan's
advice about that.
     Do we really need a new one , or can we have the 3D input in the
existing ones (basically SED/pectrum and Characterization?)

   Cheers
Fran\347ois

PS: Euro3D is an European effort to federate IFU and other 3D spectroscopy
communities. Among other things they defined a new FITS format for 3D data
and they were really missing in the IVOA discussion. So I think it's really
good news, if Giovanni and others can participate.
 See http://www.aip.de/Euro3D/

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dm@eso.org  Tue Feb 15 12:00:23 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FB060d020542
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 12:00:06 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1FB06sw020541
	for dm-outgoing; Tue, 15 Feb 2005 12:00:06 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FAxo0d020484;
	Tue, 15 Feb 2005 11:59:50 +0100 (MET)
Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FAxmhA005492;
	Tue, 15 Feb 2005 11:59:48 +0100 (CET)
Received: from cass41.ast.cam.ac.uk ([131.111.69.186]:37667)
	by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25)
	with esmtp id 1D10QY-0007aw-Li (Exim 4.44)
	(return-path <naw@ast.cam.ac.uk>); Tue, 15 Feb 2005 10:59:34 +0000
Received: from cass89.ast.cam.ac.uk (cass89 [IPv6:2001:630:200:4240:a00:20ff:feb0:c66f])
	by cass41.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j1FAxToL002758;
	Tue, 15 Feb 2005 10:59:29 GMT
Received: from cass89.ast.cam.ac.uk (localhost [127.0.0.1])
	by cass89.ast.cam.ac.uk (8.12.10+Sun/8.12.10) with ESMTP id j1FAxS8E003306;
	Tue, 15 Feb 2005 10:59:28 GMT
Received: from localhost (naw@localhost)
	by cass89.ast.cam.ac.uk (8.12.10+Sun/8.12.10/Submit) with ESMTP id j1FAxSOq003303;
	Tue, 15 Feb 2005 10:59:28 GMT
X-Authentication-Warning: cass89.ast.cam.ac.uk: naw owned process doing -bs
Date: Tue, 15 Feb 2005 10:59:28 +0000 (GMT)
From: Nicholas Walton <naw@ast.cam.ac.uk>
X-X-Sender: naw@cass89
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: 3D data model
In-Reply-To: <200502150959.KAA13600@alinda.u-strasbg.fr>
Message-ID: <Pine.GSO.4.58.0502151050580.2934@cass89>
References: <200502150959.KAA13600@alinda.u-strasbg.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
X-Cam-AntiVirus: No virus found
X-Cam-SpamDetails: Not scanned
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.15.1
X-Virus-Scanned: by amavisd-new
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mercury.hq.eso.org id j1FAxu0d020492
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Nicholas Walton <naw@ast.cam.ac.uk>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Francois,

I strongly support your concerns as to excessive fragmentation of and
within the working groups.

In terms of creation of a new working group, there is a clear process,
whereby a case is made and proposal brought forward to the IVOA Exec who
recommend or otherwise the creation of that new group. Thus, the process
recently was followed and led to the creation of the VOEvent working
group.

In terms of fragmentation within a group, i think that we should try to
avoid creating un-necessary 'de-facto' mini-working groups, which may have
the unfortunate outcome, that we end up with a proliferation of differing
'standards' addressing rather similar problems.

Perhaps at the Kyoto meeting, the DAL and DM groups could carefully assess
their current subgroups, to ensure that they are all functioning well
within the wider DM and DAL WG's.

Yours, Nic

========================================================================
Dr N. A. Walton
(AstroGrid Project Scientist	       http://www.astrogrid.org)
(Euro-VO VOTC Project Scientist	       http://www.euro-vo.org)
Institute of Astronomy          Tel:   +44 1223 337503
University of Cambridge         Fax:   +44 1223 337523
Madingley Road                  WWW:   http://www.ast.cam.ac.uk/~naw
Cambridge, CB3 0HA              email: naw@ast.cam.ac.uk
========================================================================


On Tue, 15 Feb 2005, Francois Bonnarel wrote:

> Doug, Igor, Philippe, Giovanni,
>    Sorry to have given you maybe the impression to be a little bit "chilly".
> I basically agree with what you say, Doug.
>    My main concern was about keeping a consistency in the work of the DM
> group. If "Characterization" is to be seen as some sort of federator DM
> for Observations and Datasets, we absolutly need that newcomers from the IFU
> community to have a look to the work done in Characterization.
>    So , definitly I am really happy that we discuss these topics in the group
> before and in Kyoto, and we get specialists (were they Euro3D consortiums
> participants or not) coming in for that.
>
>     What I am only reluctant to  is to create a  new DM Subgroup each time
> a new point of view is coming in.
>     Just to recall we allready have the following subgroups (or specific
> data models efforts) in the DM Working group:
>     Quantity
>     STC
>     SED/spectrum
>     Characterization (and previously Observation)
>     And since a couple of monthes: Catalog.
> In addition  the "Radio" effort was always done in close connection to
> Observation Characterization, as a kind of specialisation of it.
>     The SED/spectrum was considered to be urgent enough to be separated
> from a more general and slower effort on Characterization/Observation .
>      I am just afraid that adding new subgroups will make the whole
> Working group unmanageable and I would really like to have Jonathan's
> advice about that.
>      Do we really need a new one , or can we have the 3D input in the
> existing ones (basically SED/pectrum and Characterization?)
>
>    Cheers
> François
>
> PS: Euro3D is an European effort to federate IFU and other 3D spectroscopy
> communities. Among other things they defined a new FITS format for 3D data
> and they were really missing in the IVOA discussion. So I think it's really
> good news, if Giovanni and others can participate.
>  See http://www.aip.de/Euro3D/
>
>
>   In addition  the "Radio" effort was always done in close connection to
> Observation Characterization, as a kind of specialisation of it.
>     The SED/spectrum was considered to be urgent enough to be separated
> from a more general and slower effort on Characterization/Observation .
>      I am just afraid that adding new subgroups will make the whole
> Working group unmanageable and I would really like to have Jonathan's
> advice about that.
>      Do we really need a new one , or can we have the 3D input in the
> existing ones (basically SED/pectrum and Characterization?)
>
>    Cheers
> Fran\347ois
>
> PS: Euro3D is an European effort to federate IFU and other 3D spectroscopy
> communities. Among other things they defined a new FITS format for 3D data
> and they were really missing in the IVOA discussion. So I think it's really
> good news, if Giovanni and others can participate.
>  See http://www.aip.de/Euro3D/
>
> =====================================================================
> Francois   Bonnarel               Observatoire Astronomique de Strasbourg
> CDS (Centre de donnees          11, rue de l'Universite
> astronomiques de Strasbourg)    F--67000 Strasbourg (France)
>
> Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
> ---------------------------------------------------------------------
>

From owner-dm@eso.org  Tue Feb 15 13:49:10 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FCmq0d008826
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 13:48:52 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1FCmqqH008825
	for dm-outgoing; Tue, 15 Feb 2005 13:48:52 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FCmm0d008818;
	Tue, 15 Feb 2005 13:48:48 +0100 (MET)
Received: from sn.sai.msu.ru (sn.sai.msu.ru [195.208.220.215])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FCmk57026486;
	Tue, 15 Feb 2005 13:48:47 +0100 (CET)
Received: from sn.sai.msu.ru (localhost [127.0.0.1])
	by sn.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j1FCmesm016799;
	Tue, 15 Feb 2005 15:48:40 +0300
Received: from localhost (chil@localhost)
	by sn.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j1FCmegS016796;
	Tue, 15 Feb 2005 15:48:40 +0300
X-Authentication-Warning: sn.sai.msu.ru: chil owned process doing -bs
Date: Tue, 15 Feb 2005 15:48:40 +0300 (MSK)
From: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-X-Sender: chil@sn.sai.msu.ru
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
cc: dal@ivoa.net, dm@ivoa.net
Subject: Re: 3D data model
In-Reply-To: <200502150959.KAA13600@alinda.u-strasbg.fr>
Message-ID: <Pine.LNX.4.58.0502151521390.7123@sn.sai.msu.ru>
References: <200502150959.KAA13600@alinda.u-strasbg.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.15.3
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Francois,

For me the main idea is not to organize a group or sub-group, but just to know
the people interested in the topic and try to hear their opinions. I'm ready
to make a review of Characterization DM from the 3D point of view. We may
discuss on Thursday what should be the result (some document, some
corrections, or something else). See you soon.

With best regards,
						Igor

From owner-dal@eso.org  Tue Feb 15 14:34:57 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FDYi0d017374
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 14:34:44 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1FDYiiE017373
	for dal-outgoing; Tue, 15 Feb 2005 14:34:44 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FDYW0d017347;
	Tue, 15 Feb 2005 14:34:32 +0100 (MET)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FDYVhA011325;
	Tue, 15 Feb 2005 14:34:31 +0100 (CET)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.5pre1) with ESMTP id j1FDYPqn013425
          ; Tue, 15 Feb 2005 14:34:25 +0100 (CET)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id OAA14268;
	Tue, 15 Feb 2005 14:25:21 +0100 (MET)
Date: Tue, 15 Feb 2005 14:25:21 +0100 (MET)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200502151325.OAA14268@alinda.u-strasbg.fr>
To: igor.chilingarian@obs.univ-lyon1.fr
Subject: Re: 3D data model
Cc: dal@ivoa.net, dm@ivoa.net
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [130.79.200.1]); Tue, 15 Feb 2005 14:34:25 +0100 (CET)
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.15.4
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Igor,
  
   This looks perfect to me.
Best regards
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dm@eso.org  Tue Feb 15 17:50:41 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FGoR0d019672
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 17:50:27 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1FGoR3H019671
	for dm-outgoing; Tue, 15 Feb 2005 17:50:27 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FGoN0d019660;
	Tue, 15 Feb 2005 17:50:23 +0100 (MET)
Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FGoKhA017865;
	Tue, 15 Feb 2005 17:50:21 +0100 (CET)
Received: (from moore@localhost)
	by postal.sdsc.edu (8.11.7/8.11.7/server/68) id j1FGo8a25293;
	Tue, 15 Feb 2005 08:50:08 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06200771be36b906a418@[132.249.201.229]>
In-Reply-To: <Pine.LNX.4.44.0502141109260.5700-100000@oak>
References: <Pine.LNX.4.44.0502141109260.5700-100000@oak>
Date: Mon, 14 Feb 2005 12:26:15 -0800
To: Doug Tody <dtody@nrao.edu>
From: Reagan Moore <moore@sdsc.edu>
Subject: Re: towards 3D data model
Cc: dal@ivoa.net, <dm@ivoa.net>
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.15.8
X-Virus-Scanned: by amavisd-new
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercury.hq.eso.org id j1FGoR0d019668
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Reagan Moore <moore@sdsc.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Doug:
The Data Format Description Language group of the 
Global Grid Forum is making progress on building 
XML-based representations of the structure of 
arbitrary binary data sets. Within the year it 
should be possible to read a description of the 
structure of a data set, and then automate the 
extraction of data.

Reagan Moore



>Francois -
>
>The characterization data model (also other general dataset data models
>such as identification etc.) apply to all datasets hence would apply to
>3D data as well.
>
>For modeling 3D data in DAL, more is required as we need to model the
>actual dataset.  Currently we have 2D sky images (SIA) and various kinds of
>tabular spectrophotometric data (SSA).  My feeling is that what is required
>for spectral datacubes is a generalization of the 2D image model to 3D.
>This would build upon the spectrophotometric metadata developed for SSA to
>describe the observable, plus FITS WCS to describe the coordinate system.
>
>This is probably what is needed for regularly gridded data such as a
>spectral data cube.  It is also possible that for some data of this sort,
>e.g., MOS or IFU data where the spectra have already been extracted, that
>we should use the SSA data model instead.  It would be easy to extend
>this to collections of spectra, which is what one has in this case.
>
>It is possible that to support spectral data cubes we should just
>fold the support into a future version of SIA - whether or not this is
>advisable depends upon how much it complicates things.  It may be that
>the complications would justify a new data access interface for 3D data.
>In particular, we don't know at this point what is required to cutout
>regions of a large spectral data cube.  We need to understand the science
>drivers better to analyze this, i.e., what sorts of analysis do we want
>to target with this capability.
>
>	- Doug
>
>
>On Mon, 14 Feb 2005, Francois Bonnarel wrote:
>
>>  dear Giovanni, Phillipe and Igor,
>>     I am happy that Euro 3D people will join the IVOA data model effort
>>  This connection was missing since a long time. I am not personnaly sure
>>  that creating a specific 3D data model is the best we can do to achieve
>>  that. There is an ongoing "Characterization" data model effort supposed
>>  to deal with any kind of observations and data sets.  (material can be found
>>  on the list about that, and Giovanni, you can 
>>remember we discussed this last
>>  October). A subgroup is supposed to produce a draft long before Kyoto for
>>  discussion.
>>  My immediate proposal is that somebody among Euro3D people can join the
>>  subgroup  and judge the pertinance of the ongoing work from the 3D point
>>  of view.
>>    Your opinion about that ?
>>  Cheers
>>  François
>>
>>  =====================================================================
>>  Francois   Bonnarel               Observatoire Astronomique de Strasbourg
>>  CDS (Centre de donnees          11, rue de l'Universite
>>  astronomiques de Strasbourg)    F--67000 Strasbourg (France)
>>
>>  Tel: +33-(0)3 90 24 24 11       WWW: 
>>http://cdsweb.u-strasbg.fr/people/fb.html
>>  Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
>>  ---------------------------------------------------------------------


From owner-dm@eso.org  Tue Feb 15 19:55:42 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FItS0d005424
	for <dm-outgoing@mercury.hq.eso.org>; Tue, 15 Feb 2005 19:55:28 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1FItSNQ005423
	for dm-outgoing; Tue, 15 Feb 2005 19:55:28 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FItM0d005404;
	Tue, 15 Feb 2005 19:55:22 +0100 (MET)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1FItJ57008198;
	Tue, 15 Feb 2005 19:55:20 +0100 (CET)
Received: from dropbox.aoc.nrao.edu (dropbox [146.88.1.13])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id j1FIt8F20351;
	Tue, 15 Feb 2005 11:55:08 -0700
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by dropbox.aoc.nrao.edu (8.12.8/8.12.8/smtp-gateway) with ESMTP id j1FIt7wk025701;
	Tue, 15 Feb 2005 11:55:07 -0700
Date: Tue, 15 Feb 2005 11:55:07 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@oak
To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
cc: dal@ivoa.net, <dm@ivoa.net>
Subject: Re: 3D data model
In-Reply-To: <200502150959.KAA13600@alinda.u-strasbg.fr>
Message-ID: <Pine.LNX.4.44.0502151123070.5700-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-MailScanner-Information: Please contact postmaster@aoc.nrao.edu for more information
X-MailScanner: Found to be clean
X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.8, required 7,
	BAYES_01 -5.40, IN_REP_TO -0.37, USER_AGENT_PINE 0.00)
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.15.9
X-Virus-Scanned: by amavisd-new
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Francois -

I certainly don't think a new WG is needed, rather we should start to
look at how to deal with 3D data within DM and DAL.  Currently this is
more of a discussion topic than anything else.  While we don't know yet
what is required to address the general problem of 3D data, it is clear
that it is closely linked to image and spectral data access and we should
take this as a starting point.

The Characterization model is supposed to apply to any VO dataset which
should include 3D data.  All it does though is physically characterize
the dataset in terms of bandpass, sampling, resolution, etc.  - there are
many issues of access to 3D data which this model alone will not address.
But we would like to use the standard characterization model for all data
including 3D data.

The Euro3D effort is very interesting, I was not aware of this.  This looks
like it could help greatly to define from the data analysis side what
is required to deal with 3D data.  My main concern is that it appears to
deal mainly with O/IR spectroscopic instruments (IFU, MOS, Fabry-Perot,
etc.) but we need to consider spectral data cubes as well, e.g., from
radio or from multiband surveys.

	- Doug

From owner-dal@eso.org  Wed Feb 16 12:05:47 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1GB5RCA019193
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 16 Feb 2005 12:05:27 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1GB5RL4019191
	for dal-outgoing; Wed, 16 Feb 2005 12:05:27 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1GB5NCA019184;
	Wed, 16 Feb 2005 12:05:24 +0100 (MET)
Received: from hermes.dur.ac.uk (hermes.dur.ac.uk [129.234.4.9])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1GB5M57004398;
	Wed, 16 Feb 2005 12:05:22 +0100 (CET)
Received: from dust0.dur.ac.uk (dust0.dur.ac.uk [129.234.8.70])
	by hermes.dur.ac.uk (8.11.7-20030923/8.11.7) with ESMTP id j1GB4uQ08204;
	Wed, 16 Feb 2005 11:04:56 GMT
Received: from starpc8.phyast.dur.ac.uk (starpc8.phyast.dur.ac.uk [129.234.184.206])
	by dust0.dur.ac.uk (8.11.7+Sun/8.9.1) with ESMTP id j1GB4u108516;
	Wed, 16 Feb 2005 11:04:56 GMT
Received: from starpc8.phyast.dur.ac.uk (localhost [127.0.0.1])
	by starpc8.phyast.dur.ac.uk (8.12.8/8.12.8) with ESMTP id j1GB4u5P016110;
	Wed, 16 Feb 2005 11:04:56 GMT
Received: from localhost (pdraper@localhost)
	by starpc8.phyast.dur.ac.uk (8.12.8/8.12.8/Submit) with ESMTP id j1GB4pIW016106;
	Wed, 16 Feb 2005 11:04:56 GMT
Date: Wed, 16 Feb 2005 11:04:51 +0000 (GMT)
From: "Peter W. Draper" <p.w.draper@durham.ac.uk>
To: apps@ivoa.net, <dal@ivoa.net>
cc: Starlink development <STARDEV@jiscmail.ac.uk>
Subject: Starlink SPLAT-VO released
Message-ID: <Pine.LNX.4.44.0502161100460.4100-100000@starpc8.phyast.dur.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-DurhamAcUk-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.16.1
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: "Peter W. Draper" <p.w.draper@durham.ac.uk>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000


                         Announcing Starlink SPLAT-VO
                         ============================

The Starlink Spectral Analysis Tool (SPLAT) has been upgraded to include a
demonstration toolbox for querying, downloading and displaying spectra
from simple SSAP servers.

It is available as a download for installing onto your desktop or as a
Java webstart application for Linux (RH9+), Windows (XP), Mac OS X (10.3)  
and Solaris (8+) at:

   http://star-www.dur.ac.uk/~pdraper/splat/splat-vo

SPLAT-VO is part of the Starlink STARJAVA package and is available under the
GPL.

Highlights of this release, besides being able to make SSAP queries, are
the matching of spectral coordinates and fluxes between spectra. Spectral
coordinates include the full range described in FITS WCS Paper III, that
is wavelength, frequency, energy and velocity etc. These can be described
in various rest frames -- topocentric, heliocentric, dynamic and kinematic
local -- and can be transformed between them all.

Differences between data value units can be automatically taken account of
when overlaying spectra as long as the units strings conform to the system
described in FITS WCS paper I. Also, automatic identification and
conversion between flux per unit wavelength and flux per unit frequency is
provided and does not require any "dimensional analysis" information to be
present

These two systems will be extended to include others such as magnitude and
antenna temperature that require additional meta-data to fully describe
the inter-system transformations. All coordinate and flux transformations
are handled by the Starlink AST package, developed by Rodney Warren-Smith
and David Berry (dsb@ast.man.ac.uk). AST also provides the plotting
facilities used for drawing spectra in SPLAT-VO.

Naturally such an early implementation has many limitations -- the server
list is currently fixed (not for long), the queries only use the basic set
of parameters (position and radius) and the returned spectra may only be
simple FITS or VOTables, but it is hoped to be of some use.

Cheers,

Peter.

--
Dr. Peter W. Draper, Starlink Programmer,    http://star-www.dur.ac.uk/~pdraper

From owner-dal@eso.org  Thu Feb 17 21:01:53 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HK1UhW028008
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 17 Feb 2005 21:01:30 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1HK1U1U028007
	for dal-outgoing; Thu, 17 Feb 2005 21:01:30 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HK1IhW027941;
	Thu, 17 Feb 2005 21:01:18 +0100 (MET)
Received: from sn.sai.msu.ru (sn.sai.msu.ru [195.208.220.215])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HK1G57005097;
	Thu, 17 Feb 2005 21:01:16 +0100 (CET)
Received: from sn.sai.msu.ru (localhost [127.0.0.1])
	by sn.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j1HK17sm007118;
	Thu, 17 Feb 2005 23:01:07 +0300
Received: from localhost (chil@localhost)
	by sn.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j1HK16r0007115;
	Thu, 17 Feb 2005 23:01:06 +0300
X-Authentication-Warning: sn.sai.msu.ru: chil owned process doing -bs
Date: Thu, 17 Feb 2005 23:01:06 +0300 (MSK)
From: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-X-Sender: chil@sn.sai.msu.ru
To: Doug Tody <dtody@nrao.edu>
cc: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>, dal@ivoa.net,
        dm@ivoa.net, giovanni.covone@oamp.fr, prugniel@obs.univ-lyon1.fr
Subject: 3D data model: plan
In-Reply-To: <Pine.LNX.4.44.0502151123070.5700-100000@oak>
Message-ID: <Pine.LNX.4.58.0502172209230.7123@sn.sai.msu.ru>
References: <Pine.LNX.4.44.0502151123070.5700-100000@oak>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.17.10
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

Hello Doug,

Today I discussed with Francois some questions concerning 3D data model

Your idea about science case driven approach is a perfect proposition.

I have a kind of plan for what to do for a moment:
  1) Define clearly the science case for IFU data I'm working on: studies of
      stellar populations in nearby galaxies using absorption-line spectra
  2) During the next week hopefully we'll have two science cases formulated
      for Fabry-Perot data: studies of the gaseous kinematics in disc
      galaxies, and studies of gaseous shells (SN remnants) in nearby
      galaxies. I asked scientits working with this type of data to describe
      these cases.

 Each of these science cases will be presented as a short part of text (15-20
lines) including scientific objectives and brief description of the scientific
data processing with the requiremets about the descripition of the data.
It should help to figure out the requirements for the 3D data model, and
for 3D data access layer. We'll probably need the same to be done for
other 3D data types, but I don't know personally people working with radio
and X-ray cubes.

  3) As Francois proposes me, I'll try to add the necessary features to the
      Characterisation data model to be able to deal with the IFU data.
      I'll do my best to finish this (with a help of Francois) before the
      end of March
  4) At this point it will be clear (hopefully) what we need to have in the
      3D data model, and whether we need it separated from more general DMs
      (Characterization and Observation), and it would be possible to start
      the real work on the document draft.

Do you agree on such a plan?

With best regards,
						Igor

From owner-dal@eso.org  Thu Feb 17 21:29:26 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HKTBhW002094
	for <dal-outgoing@mercury.hq.eso.org>; Thu, 17 Feb 2005 21:29:11 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1HKTBrA002093
	for dal-outgoing; Thu, 17 Feb 2005 21:29:11 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HKT3hW002079;
	Thu, 17 Feb 2005 21:29:03 +0100 (MET)
Received: from mailhost.jach.hawaii.edu (mailhost.jach.HAWAII.EDU [128.171.90.17])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HKT157005794;
	Thu, 17 Feb 2005 21:29:01 +0100 (CET)
Date: Thu, 17 Feb 2005 10:28:51 -1000 (HST)
From: Tim Jenness <t.jenness@jach.hawaii.edu>
To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>
cc: Doug Tody <dtody@nrao.edu>,
        Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>, dal@ivoa.net,
        dm@ivoa.net, giovanni.covone@oamp.fr, prugniel@obs.univ-lyon1.fr
Subject: Re: 3D data model: plan
In-Reply-To: <Pine.LNX.4.58.0502172209230.7123@sn.sai.msu.ru>
Message-ID: <Pine.LNX.4.58.0502171018450.12177@yncnxv>
References: <Pine.LNX.4.44.0502151123070.5700-100000@oak>
 <Pine.LNX.4.58.0502172209230.7123@sn.sai.msu.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.17.11
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Tim Jenness <t.jenness@jach.hawaii.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000


The JCMT will be happy to contribute science cases and comments on data
models for 3D data. We generate data cubes from our correlator (calibrated
in antenna temperature but that's a argument for a different dm thread!)
We (the JAC) also have an IFU on UKIRT that drives our desire to have 
something that will work in the infrared and submm.

Slightly tangential, but we did do an analysis of submm requirements for 
applications using cube data (at ADASS) if anyone is interested:

  http://www.jach.hawaii.edu/software/pubs/adass2004_p2_1_15.pdf

Tim

On Thu, 17 Feb 2005, Igor Chilingarian wrote:

> Hello Doug,
> 
> Today I discussed with Francois some questions concerning 3D data model
> 
> Your idea about science case driven approach is a perfect proposition.
> 
> I have a kind of plan for what to do for a moment:
>   1) Define clearly the science case for IFU data I'm working on: studies of
>       stellar populations in nearby galaxies using absorption-line spectra
>   2) During the next week hopefully we'll have two science cases formulated
>       for Fabry-Perot data: studies of the gaseous kinematics in disc
>       galaxies, and studies of gaseous shells (SN remnants) in nearby
>       galaxies. I asked scientits working with this type of data to describe
>       these cases.
> 
>  Each of these science cases will be presented as a short part of text (15-20
> lines) including scientific objectives and brief description of the scientific
> data processing with the requiremets about the descripition of the data.
> It should help to figure out the requirements for the 3D data model, and
> for 3D data access layer. We'll probably need the same to be done for
> other 3D data types, but I don't know personally people working with radio
> and X-ray cubes.
> 
>   3) As Francois proposes me, I'll try to add the necessary features to the
>       Characterisation data model to be able to deal with the IFU data.
>       I'll do my best to finish this (with a help of Francois) before the
>       end of March
>   4) At this point it will be clear (hopefully) what we need to have in the
>       3D data model, and whether we need it separated from more general DMs
>       (Characterization and Observation), and it would be possible to start
>       the real work on the document draft.
> 
> Do you agree on such a plan?
> 
> With best regards,
> 						Igor
> 

-- 
Tim Jenness
Head of JAC Scientific Computing Group
http://www.jach.hawaii.edu/~timj

From owner-dm@eso.org  Thu Feb 17 22:48:40 2005
Return-Path: <owner-dm@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HLmQhW012862
	for <dm-outgoing@mercury.hq.eso.org>; Thu, 17 Feb 2005 22:48:26 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1HLmQwX012861
	for dm-outgoing; Thu, 17 Feb 2005 22:48:26 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HLmGhW012845;
	Thu, 17 Feb 2005 22:48:16 +0100 (MET)
Received: from virgo.sdc.org (virgo.sdc.org [209.155.42.1])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1HLmEhA026344;
	Thu, 17 Feb 2005 22:48:14 +0100 (CET)
Received: from lepus.tuc.noao.edu (dtody [209.155.156.44])
	by virgo.sdc.org (8.12.8/8.12.8) with ESMTP id j1HLlrNu025493;
	Thu, 17 Feb 2005 14:47:54 -0700
Date: Thu, 17 Feb 2005 14:47:52 -0700 (MST)
From: Doug Tody <dtody@nrao.edu>
X-X-Sender: dtody@lepus.tuc.noao.edu
To: Igor Chilingarian <igor.chilingarian@obs.univ-lyon1.fr>,
        Tim Jenness <t.jenness@jach.hawaii.edu>
cc: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>, dal@ivoa.net,
        dm@ivoa.net, giovanni.covone@oamp.fr, prugniel@obs.univ-lyon1.fr
Subject: Re: 3D data model: plan
In-Reply-To: <Pine.LNX.4.58.0502172209230.7123@sn.sai.msu.ru>
Message-ID: <Pine.LNX.4.61.0502171427590.6404@lepus.tuc.noao.edu>
References: <Pine.LNX.4.44.0502151123070.5700-100000@oak>
 <Pine.LNX.4.58.0502172209230.7123@sn.sai.msu.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: by amavisd-new
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.17.12
Sender: owner-dm@eso.org
Precedence: bulk
Reply-To: Doug Tody <dtody@nrao.edu>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Igor, Tim -

This looks like exactly what is needed at this point.  We need to
understand better the data we are dealing with, from IFU data to radio
spectral image cubes, and how we would like to deal with it for analysis.
Representative use-cases are a good way to address this.  We want to end
up with interfaces and tools which are multiwavelength and can be used
for all such data.

Some specific comments:

On Thu, 17 Feb 2005, Igor Chilingarian wrote:
> Today I discussed with Francois some questions concerning 3D data model

Remember, it is not just the abstract data model, we also need to consider
what is required for actual data access and analysis.  In fact I think
we should start with the latter, plus list the data instances we want to
support, and only at the end of this analysis try to define the required
data models or extensions to data models.

> Your idea about science case driven approach is a perfect proposition.
>
> I have a kind of plan for what to do for a moment:
>  1) Define clearly the science case for IFU data I'm working on: studies of
>      stellar populations in nearby galaxies using absorption-line spectra
>  2) During the next week hopefully we'll have two science cases formulated
>      for Fabry-Perot data: studies of the gaseous kinematics in disc
>      galaxies, and studies of gaseous shells (SN remnants) in nearby
>      galaxies. I asked scientits working with this type of data to describe
>      these cases.
>
> Each of these science cases will be presented as a short part of text (15-20
> lines) including scientific objectives and brief description of the scientific
> data processing with the requiremets about the descripition of the data.
> It should help to figure out the requirements for the 3D data model, and
> for 3D data access layer. We'll probably need the same to be done for
> other 3D data types, but I don't know personally people working with radio
> and X-ray cubes.

Yes.  Also Tim's examples of JCMT radio and IFU data, or anyone else who
wants to volunteer to contribute use-cases.

>  3) As Francois proposes me, I'll try to add the necessary features to the
>      Characterisation data model to be able to deal with the IFU data.
>      I'll do my best to finish this (with a help of Francois) before the
>      end of March

>  4) At this point it will be clear (hopefully) what we need to have in the
>      3D data model, and whether we need it separated from more general DMs
>      (Characterization and Observation), and it would be possible to start
>      the real work on the document draft.

Yes, but remember that Characterization is a general model and is not
specific to any particular kind of data.  Hence we don't want to be adding
"observational" metadata into this to describe specific data types.  We
may need to do that, but such specialized information should go elsewhere.

At the level of data characterization a 3D dataset merely has a certain
bandpass, resolution, sample size, etc. in each physical axis (spatial,
spectral, time).  The difference between a 2D image and a 3D spectral data
cube is merely that there are multiple samples along the spectral axis.
The difference between IFU data and a regularly sampled spectral data
cube might not be visible at this level, except perhaps for subtleties
like the filling factor in the spatial domain.

For actual 3D datasets, some like spectral data cubes might be best handled
by generalizing the image model to 3D.  Others like IFU data might be
best handled by a collection of extracted 1D spectra (e.g. SSA using a
FITS binary table), or maybe a 3D image with a spatial mask and other
metadata, or maybe via a new model or subclass specific to this data if
it is complex enough to require it.  To fully address this problem might
require some combination of all of these.  I doubt if we want to try to
generate one model with covers everything as it will be too complex.

 	- Doug

From owner-dal@eso.org  Fri Feb 18 13:12:15 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ICBpmD024859
	for <dal-outgoing@mercury.hq.eso.org>; Fri, 18 Feb 2005 13:11:51 +0100 (MET)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j1ICBpLY024858
	for dal-outgoing; Fri, 18 Feb 2005 13:11:51 +0100 (MET)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ICBjmD024846
	for <dal@ivoa.net>; Fri, 18 Feb 2005 13:11:45 +0100 (MET)
Received: from ns1.u-strasbg.fr (ns1.u-strasbg.fr [130.79.200.1])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j1ICBh57004833
	for <dal@ivoa.net>; Fri, 18 Feb 2005 13:11:44 +0100 (CET)
Received: from alinda.u-strasbg.fr (alinda.u-strasbg.fr [130.79.128.41])
          by ns1.u-strasbg.fr (8.12.9p2/jtpda-5.5pre1) with ESMTP id j1ICBbqn088869
          ; Fri, 18 Feb 2005 13:11:37 +0100 (CET)
Received: (from bonnarel@localhost)
	by alinda.u-strasbg.fr (8.8.8+Sun/8.8.8) id NAA13041;
	Fri, 18 Feb 2005 13:02:30 +0100 (MET)
Date: Fri, 18 Feb 2005 13:02:30 +0100 (MET)
From: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
Message-Id: <200502181202.NAA13041@alinda.u-strasbg.fr>
To: dtody@nrao.edu, igor.chilingarian@obs.univ-lyon1.fr
Subject: Re: 3D data model: plan
Cc: dal@ivoa.net, giovanni.covone@oamp.fr, jcm@head.cfa.harvard.edu,
        prugniel@obs.univ-lyon1.fr
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.3 (ns1.u-strasbg.fr [130.79.200.1]); Fri, 18 Feb 2005 13:11:37 +0100 (CET)
X-Antivirus: scanned by sophos at u-strasbg.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2005.2.18.3
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Francois Bonnarel <bonnarel@alinda.u-strasbg.fr>
X-Mozilla-Status: 8011
X-Mozilla-Status2: 00000000

Dear Igor,
    The discussion of yestarday was really interesting.
    Anyway, I think there was a small misunderstanding about 
    point 3 )   

<  3) As Francois proposes me, I'll try to add the necessary features to the
<      Characterisation data model to be able to deal with the IFU data.
<      I'll do my best to finish this (with a help of Francois) before the
<      end of March

     My proposal was for you to review the predraft of the 
Characterization from the 3D point of view. "Can an IFU be Characterized" with the present status of characterization or not, and if not
what can we do with the minimum change to do it.



<  4) At this point it will be clear (hopefully) what we need to have in the
<      3D data model, and whether we need it separated from more general DMs
<      (Characterization and Observation), and it would be possible to start
<      the real work on the document draft.
<
<Do you agree on such a plan?
   I am afraid it will not go so fast, before we would have to 
finalize SED and Characterization first (up to recommendation) .


By the way  I would like to (kindlyand just for next time) caution 
you about copying such mail about an informal discussion who at 
least had to be validated by Doug/and or jonathan as leaders of 
the groups to the dm list.

Just because this can add confusion to the people not aware of all
the details


Cheers
François

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel@astro.u-strasbg.fr
---------------------------------------------------------------------

From owner-dal@eso.org  Wed Apr 13 22:22:05 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3DKLhaR018222
	for <dal-outgoing@mercury.hq.eso.org>; Wed, 13 Apr 2005 22:21:43 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j3DKLhjS018221
	for dal-outgoing; Wed, 13 Apr 2005 22:21:43 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from rocky.hq.eso.org (rocky.hq.eso.org [134.171.42.43])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3DKLZaR018212
	for <dal@ivoa.net>; Wed, 13 Apr 2005 22:21:35 +0200 (MEST)
Received: from donner.stsci.edu (donner.stsci.edu [130.167.251.65])
	by rocky.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3DKLWG8007409
	for <dal@ivoa.net>; Wed, 13 Apr 2005 22:21:33 +0200 (CEST)
Received: from [130.167.237.248] (atman.stsci.edu [130.167.237.248])
	by donner.stsci.edu (MOS 3.5.8-GR)
	with ESMTP id BPT17175;
	Wed, 13 Apr 2005 16:20:50 -0400 (EDT)
Message-ID: <425D7F5D.3030201@stsci.edu>
Date: Wed, 13 Apr 2005 16:21:49 -0400
From: Randall Thompson <rthomp@stsci.edu>
Organization: STScI
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dal@ivoa.net
CC: Randall Thompson <rthomp@stsci.edu>
Subject: FITS Serialization Questions for SSAP 0.93
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Junkmail-Status: score=0/50, host=donner.stsci.edu
X-Scanned-By: MIMEDefang 2.35
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.4.13.11
X-Virus-Scanned: by amavisd-new
Sender: owner-dal@eso.org
Precedence: bulk
Reply-To: Randall Thompson <rthomp@stsci.edu>
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000

We are continuing to work on producing SSAP-compatible FITS files
for MAST and HST.  A  few questions came up in the process.

1) Most of our spectral FITS files have general parameters stored in the 
primary
 headers (e.g., DATE) and I was hoping to leave these intact when 
creating the new
versions. Does the SSAP require the specified keywords to appear in the 
extension
headers? Obviously some are required there.

2)  We have at least 3 missions containing echelle spectra. Typically 
each spectral
order has a different number of data points. I assume the recommended
way to store these would be as multiple rows in a binary table using 
variable length
arrays.  Is this correct? Do you recommend any format which would not 
require the
use of variable length arrays (other than writing them to separate 
files)? I was wondering
for example about using padded zeroes to store multiple orders in a 
single binary table,
or having multiple binary table extensions, one for each spectral order.

3) I know the SED data model paper is not yet complete, but it would be 
useful to
have more information on defining the listed FITS keywords (e.g., the 
curation and WCS
entries).

Randy

    

From owner-dal@eso.org  Tue Apr 19 17:41:58 2005
Return-Path: <owner-dal@eso.org>
Received: from mercury.hq.eso.org (localhost [127.0.0.1])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3JFfUoj024866
	for <dal-outgoing@mercury.hq.eso.org>; Tue, 19 Apr 2005 17:41:31 +0200 (MEST)
Received: (from majordomo@localhost)
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10/Submit) id j3JFfUqc024863
	for dal-outgoing; Tue, 19 Apr 2005 17:41:30 +0200 (MEST)
X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dal@eso.org using -f
Received: from apollo.hq.eso.org (apollo.hq.eso.org [134.171.42.42])
	by mercury.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3JFfQoj024848
	for <dal@ivoa.net>; Tue, 19 Apr 2005 17:41:26 +0200 (MEST)
Received: from revere.aoc.nrao.edu (revere.aoc.nrao.edu [146.88.1.15])
	by apollo.hq.eso.org (8.12.10+Sun/8.12.10) with ESMTP id j3JFfN73001720
	for <dal@ivoa.net>; Tue, 19 Apr 2005 17:41:24 +0200 (CEST)
Received: from dropbox.aoc.nrao.edu (dropbox [146.88.1.13])
	by revere.aoc.nrao.edu (8.11.6/8.11.6) with ESMTP id j3JFfEF28233;
	Tue, 19 Apr 2005 09:41:14 -0600
Received: from oak.aoc.nrao.edu (oak.aoc.nrao.edu [146.88.3.232])
	by dropbox.aoc.nrao.edu (8.1
