• A "README" file that includes file descriptions and documents details of data reduction, pipeline processing version is required.
• Plots relevant to the HLSP and quicklook/preview images in common display formats such as PostScript, GIF, JPEG, PNG and PDF.
• Thoroughly tested and well-documented, specialized, analysis software relevant to the HLSP, Java applets, and other image display software. (MAST will archive such software but will not accept responsibility for maintaining it).

• Literature, including paper preprints and reprints
• Analysis products several steps removed from the HLSP (e.g. IDL save-sets, intermediate products)

• FITS files are the preferred format for most data types (images, spectra, catalogs, etc.) [see FITS rules below]
• Plain text ASCII (e.g. README files, catalogs in an allowed journal format, some software)
• PDF (plots, and large README files)
• Any common image format (e.g. GIF, JPEG, PNG) for preview, color and annotated images (MPEG is also allowed)

Unacceptable formats

• File formats specific to particular software such as Microsoft, Tex, LaTex, and IDL save-set formats.

• The required naming scheme is:

  hlsp_project_mission_instrument(-resolution)_field-name_filter_version_product.extension

  
  
  • hlsp - identifies the file as a community-contributed dataset.
  • project - An agreed upon name for the HLSP set. This name is also used as directory name and as a database keyword.
  • mission - Mission/missions acquiring the data. If two missions used they should be separated by hyphens; models/simulations can be indicated here.
  • instrument - Instrument (e.g. acs-wfc). When not applicable as for GALEX data, a description like imaging or spectra should be used. Resolution with units can be specified following a dash (e.g. 'asc-30mas' indicates ACS instrument with 30 milliarcsecond resolution)
  • field-name - Field name or target as designated by the team. Parts, counter numbers and epochs are allowed in this field and should be separated by hyphens. If using multiple epochs, please use suffix 'ep' followed by a number (e.g. M101-ep1, M101-ep2). Counters can be used when the same field is observered N times with same observing parameters. For parts and counteres, we require leading zeros if more than 1 digit is needed (e.g. for 17 exposures of M101, each file has field-name as follows: M101-01, M101-02 ... M101-09 ... M101-17; similarly, for more than 9 epochs: M101-ep01 ... M101-ep19). Please describe your usage of field-name parts and counters within the README.
  • filter - Filter or filters used; or, grating(s) used. If HST this should be the full filter/grating name (e.g. f606w or ge230m). If more than one filter is used, separate the filters by hyphens (e.g. f606w-f814w).
  • version - Version Number, such as v#.# or v#. e.g. v2.4
  • product - Type of data as designated by the team (models/simulations can be indicated here). e.g. img, drz, sci, weight, wht, cat, modelmap, theory, sim, model, map and SED.
  • extension - Standard file extension. e.g. fits, txt, jpg
  
  
• Use lower case characters only.
• Use underscores ONLY to delineate between major fields (e.g. "goods_hst")
• Within fields, dashes can be used as separators (e.g. "nicmos-nic3", "acs-wfc", "M101-01")
• Version numbers can be specific to the project. We recommend teams use increased version numbers to indicate data which are superseded; we will NOT keep older versions of datasets unless the team explicitly requests this. Note that sometimes version number will denote single-EPOCH data as in GOODS; this sort of information must be documented well with deliveries.
• We recommend data are re-delivered with higher version numbers (better products); we recommend that the newest deliveries contain both the re-processed data along with the single-epoch data associated with these products, if applicable.
• We recommend that images from different filters that have the same field-name should have matching sizes and WCS coordinates. All images identified using the same field-name should cover the same part of the sky. If there are multiple images covering different parts of an object, they should have different field-names.

  Examples:
  hlsp_goods_hst_acs-wfc_north-sect13_f435w_v2.0_drz.fits
  hlsp_angst_hst_wfpc2_11307-ngc0055-wide2_f606w-f814w_v1_gst.fits
  hlsp_cosmos_galex_imaging_cosmos-01_fuv_v2_int.fits
  hlsp_udf_hst_nicmos-nic3_treasury_f110w_v2_img.fits
  hlsp_clash_hst_acs-30mas_a209_f435w_v1_drz.fits
  hlsp_myproj_hst_stis_hd12345_ge230m_v1_sci.fits

The optional 'CITATION' keyword can be used in the FITS header to indicate how one would cite these data in their publication.

Additionally please list a pointer to MAST's citation and data-use policy within the README file.

• Name of a Contact Investigator for the program, along with contact information including email address and telephone number
• Program of origin, e.g., HST/Treasury for HST Treasury program data, or HST/GO for HST Guest Observer data; Contribution from an ADP, LTSA or AISRP programs.
• The program number, if there is any, e.g., HST proposal ID or ADP number
• The primary target of the observations, e.g. "Hubble Deep Field" or "NGC1068"
• A list of the missions from which the HLSP are derived, e.g., HST, IUE, and GALEX
• References of up to three papers closely related to the contributed HLSP, excluding authors, in standard format, e.g., 2001, ApJ, 551, 23

It is important that contributors designate a contact person who will be available to answer technical questions from users regarding details of the actual observations, the processing techniques, or scientific quality issues that MAST may not be in a position to answer. From experience, we expect that such queries will be infrequent.

We have developed web sites ranging from full search interfaces (e.g.: FUSE Magellanic Clouds Legacy Project and GALEX Atlas) to simple pages pointing to the data and the teams website (e.g.: CLASH, PHAT and UDF). Some studies have shown that urls published in scientific journals have an average lifetime of about 18 months. Maintaining the data and web pages at MAST will insure that the site is active indefinitely.

Even if you are planning your own web site, we will want to archive the data at MAST where we can provide a long-term home for it. We also request that your web site points to the data here rather than to a local copy. That ensures that the same data gets delivered from both sites and allows us to easily and consistently track use of the products from the Treasury programs. We can also more easily integrate these valuable products with our other search interfaces.