SBN Style Sheet for
PDS Data Labels and ODL Files

Please Note: This style sheet applies specifically to datasets destined for ingest by the Small Bodies Node. Some SBN requirements are stricter than general PDS requirements in order to more easily accommodate automatic processing at the node. SBN requirements which appear to place an undue burden on the data producer are, of course, open to negotiation.

This stylesheet will be expanded and updated continuously with our experience. The last revision was: Friday, 20-Jul-2001 13:17:33 EDT

Index

1. ODL, General
2. Product Labels, General
3. Product Labels, Tables
4. Product Labels, Images

10. Data Files, General
11. Data Files, ASCII Tables
12. Data Files, Binary Tables
13. Data Files, Images
14. Data Files, FITS Data

20. Catalog Objects, General
21. DATA_SET Objects
22. DATA_SET_COLLECTION Objects
23. INSTRUMENT Objects
24. INSTRUMENT_HOST Objects
25. MISSION Objects
26. REFERENCE Objects
27. TARGET Objects
28. VOLUME Objects

31. DOCUMENT Files

50. Identification Fields, General
51. Asteroid Identifications
52. Comet Identifications

Index

1. ODL, General

1.1: PDS_VERSION_ID must be the first keyword encountered in all ODL files.
1.2: All "=" characters in the label must be at least locally aligned (see the example in item 2.9). Alternately, the "=" characters may be globally aligned. (PDS keyword names are limited to 30 characters.)
1.3: In nested objects, all object-level keywords must appear prior to the first sub-object definition. Object-level keywords may not appear between sub-object definitions, nor may they appear following the last END_OBJECT line of the sub-object list.
1.4: All END_OBJECT keywords must have an object type value equal to that for the corresponding OBJECT keyword.
1.5: All quotes surrounding keyword values must be double quotes. Inside text values, single quotes must be used. There is no way to imbed a double quote into a PDS keyword string value.
1.6: The prose keywords (those ending in "_DESC","_DESCRIPTION", or "_NOTE") and the SBN-local keyword PRODUCT_NAME, can and should have mixed-case values. All other string-valued keywords must be in all uppercase, with the exception of file pointers, which must be in the same case as the corresponding file name.
1.7: String values for non-prose keywords may either be enclosed in quotes and have imbedded blanks but no underscores; or may omit the quotes and replace the imbedded blanks with underscores. Never use underscores within a quoted string value.
1.8: Gratuitous comments should be avoided. Comments should not provide information on the data itself (that should be included in the appropriate prose keyword). Comments should be included to clarify pathological uses of ODL. Comments should be offset by at least one blank line above and below. In-line comments are appropriate only rarely.
1.9: All keywords must be in all uppercase.

2. Product Labels, General

2.1

SFDU labels may not be included in SBN archive product labels unless they are specifically required by the data preparer's institution.

2.2

The PRODUCT_ID for each file must be unique across the delivery. The format for the PRODUCT_ID string is:

[dataset acronym]-[filename]-[YYYYMM]

where:

dataset acronym is the DATA_SET_ACRONYM found in the corresponding DATA_SET object, if any;
filename is the name of the data file, without extension; and
YYYYMM is the year and month (01-12) of the review in which the dataset was accepted.

Note that DATA_SET_ACRONYM is only used in those data sets which will reside in the SBN on-line archives; publication volumes need not include that keyword unless the data preparers prefer it.

2.3

PRODUCT_CREATION_TIME is the date on which the major editing of the file was completed. It should be accurate to at least a day. It must be updated whenever any datum is changed. Minor cosmetic changes in format do not require an update to this keyword.

2.4

All file names in pointer values must be in double quotes and must correspond exactly in case to the actual file name. Note: File names may not be in mixed case.

2.5

LABEL_REVISION_NOTE is optional in product labels. When present, it must follow the same format restrictions indicated for other ODL files.

2.6

OBSERVER_FULL_NAME is optional, but should be supplied wherever it makes sense to do so. It must contain either the name of the principal observer, or, in the case of a compilation catalog, the name of the person who created the compilation. It must follow the format specified for this keyword in all ODL files.

2.7

The preferred order for keywords in product labels is as follows:

PDS_VERSION_ID
LABEL_REVISION_NOTE (optional)
Cataloging keywords (PRODUCT_ID, PRODUCT_NAME, DATA_SET_ID, ...)
File Parameters (RECORD_LENGTH, RECORD_TYPE, ...)
Data Pointers (^HEADER, ^TABLE, ...)
Observational Parameters (OBSERVER_FULL_NAME, DETECTOR_TEMPERATURE, ...)
Object Definitions

2.8

All file-level keywords must appear prior to the first object definition. No file-level keywords may be inserted between object definitions nor appear after the last END_OBJECT keyword.

2.9

Keywords falling within an OBJECT definition must be indented regularly, and by at least two spaces from the initial "OBJECT = type" line. The END_OBJECT line must align with the OBJECT line. Nested objects must be similarly indented. For example:

    ^TABLE    = "test.tab"

    OBJECT     = TABLE
      NAME        = "TEST TABLE"
      COLUMNS     = 2
      ROW_BYTES   = 78
      ...
      OBJECT     = COLUMN
        COLUMN_NUMBER = 1
        NAME          = "ID"
        ...
      END_OBJECT = COLUMN

      OBJECT     = COLUMN
        COLUMN_NUMBER = 2
        NAME          = "TIME"
        ...
      END_OBJECT = COLUMN
      ...
    END_OBJECT = TABLE

2.10

All data OBJECT definitions must include a NAME.

2.11

All non-trivial or non-obvious OBJECTs must contain a useful and meaningful DESCRIPTION.

2.12

In archive products, each label should correspond to exactly one data file.

2.13

SBN labels of products destined for the on-line archives must be entirely self-contained. That is, no pointers to structure files are allowed. In all other cases structure files should be used only when strongly warranted.

3. Product Labels, Tables

3.1

In ASCII TABLEs, all COLUMN objects must contain the following keywords:

COLUMN_NUMBER: numbered in order by START_BYTE

NAME

START_BYTE: The first byte in the field (see also 3.14)
BYTES: The total number of bytes in the field (see also 3.14)
FORMAT
DATA_TYPE
DESCRIPTION

3.2

In ASCII TABLEs, numeric DATA_TYPEs must be one of the following:

ASCII_INTEGER
ASCII_REAL
ASCII_COMPLEX

3.3

In binary TABLEs, all COLUMN objects must contain the following keywords:

COLUMN_NUMBER: numbered in order of START_BYTE
NAME
START_BYTE
BYTES
DATA_TYPE
DESCRIPTION

3.4

In binary TABLEs, numeric DATA_TYPEs must indicate byte ordering (MSB vs LSB) for integers and bit strings. Real numbers must be in IEEE format, with a DATA_TYPE of IEEE_REAL or IEEE_COMPLEX.

3.5

All numeric COLUMN definitions should include the UNIT keyword unless the value being described is truly unitless. Valid units and abbreviations must be used in this field. These are described in the PDS Standards Document. This field must be in uppercase

3.6

When a COLUMN contains a one- or two-byte code (representing a reference, instrument configuration, observing note, etc.), the code translation must be provided. If the complete list of code values and explanations is brief (< 6 lines, e.g.), the definition may be included in the corresponding DESCRIPTION field. In this case they must be offset from the rest of the explanatory text and listed in an easy-to-read, tabular format. In all other cases the definitions should be provided in a separate file, sorted on the code values and with appropriate PDS labelling and documentation.

3.7

COLUMN objects can and should contain ITEMS when the field being described is logically (and physically) a vector.

3.8

The following numeric flag constants should be used where appropriate:

INVALID_CONSTANT: Data were recorded, but determined to be invalid.
MISSING_CONSTANT: Data were not recorded (due to drop-out, instrument failure, etc.).
NOT_APPLICABLE_CONSTANT: The datum described is not relevant to this record (usually found in tables of derived values).
UNKNOWN_CONSTANT: Data were presumably recorded, but were lost or unrecoverably corrupted.

3.9

MAXIMUM and MINIMUM need not be provided for columns where the values should be obvious (RA and Dec, for example), or where they do not provide any useful guidance (for a sequence counter column, e.g.). They should always be provided as a check point when the extrema may cause the user to question the validity of the data. The MAXIMUM and MINIMUM keywords always refer to the values which actually occur in the file (i.e., before scaling and offset adjustments). MAXIMUM and MINIMUM should be used more frequently in binary files, to provide a guide for users who may have difficulty reading the data in formats foreign to their own architecture.

3.10

DERIVED_MINIMUM and DERIVED_MAXIMUM, when used, should always be used in conjunction with MAXIMUM and MINIMUM, to demonstrate the effect of SCALING_FACTOR and OFFSET on the actual extrema in the data.

3.11

For data sets destined for the on-line archives, there may be no more than one TABLE object in a label, and consequently no more than one TABLE object in a data file. The only other object which is may be present in a data file containing a TABLE is a HEADER object. In an ASCII file, this HEADER should contain column labels.

When necessary, publication volumes may contain data files with multiple tables and additional objects, but the format selection must be justified.

3.12

COLUMNs must be defined and numbered (via COLUMN_NUMBER) in the order in which they occur in the physical record (i.e., by START_BYTE values). Exception: Overlapping column definitions (see item 3.13).

3.13

Column definitions should not overlap (i.e., START_BYTE[i]+BYTES[i] must be <= START_BYTE[i+1]) unless there is a compelling reason to provide secondary definitions for some columns. For example, a time field may be defined primarily as separate fields for year, day, month, etc., and also as a time string spanning all the constituent columns, for use by a software system. In the latter case the primary definition(s) should appear in the appropriate place in the label, and the alternate field definitions should be grouped together at the bottom of the COLUMN list. The alternate field designations should also be listed in their physical order. (Note that COLUMN_NUMBER should continue to increase monotonically.) For example:

OBJECT     = TABLE

  ...[ 2 COLUMN definitions ]...

  OBJECT     = COLUMN
    COLUMN_NUMBER  = 3
    NAME           = OBSERVATION_TIME
    START_BYTE     = 10
    BYTES          = 19
    DATA_TYPE      = TIME
    FORMAT         = A19
    DESCRIPTION    = "Time of the observation in standard UTC format"
  END_OBJECT = COLUMN

  ...[ 5 more COLUMN definitions ]...

  /* Auxiliary COLUMN definitions for elements of the OBSERVATION_TIME: */

  OBJECT     = COLUMN
    COLUMN_NUMBER = 9
    NAME          = OBSERVATION_YEAR
    START_BYTE    = 10
    BYTES         = 4
    DATA_TYPE     = ASCII_INTEGER
    FORMAT        = I4
    DESCRIPTION   = "Year part of the OBSERVATION_TIME"
  END_OBJECT = COLUMN

  OBJECT     = COLUMN
    COLUMN_NUMBER = 10
    NAME          = OBSERVATION_MONTH
    START_BYTE    = 15
    BYTES         = 2
    DATA_TYPE     = ASCII_INTEGER
    FORMAT        = I2
    DESCRIPTION   = "Month part of the OBSERVATION_TIME"
  END_OBJECT = COLUMN

  ...[ etc. ]...

  OBJECT     = COLUMN
    COLUMN_NUMBER = 14
    NAME          = OBSERVATION_SECONDS
    START_BYTE    = 28
    BYTES         = 2
    DATA_TYPE     = ASCII_INTEGER
    FORMAT        = I2
    DESCRIPTION   = "Integer seconds of OBSERVATION_TIME"
  END_OBJECT = COLUMN
END_OBJECT = TABLE

3.14

The gutter space between columns in an ASCII table (that is, the one or two blank bytes inserted between columns for readability) should not be considered part of the field or added into the START_BYTE or BYTES values.

4. Product Labels, Images

4.1

All image product labels must contain the following display orientation keywords with appropriate values:

LINE_DISPLAY_DIRECTION
SAMPLE_DISPLAY_DIRECTION

4.2

All archive image products must contain full pointing information in an appropriate coordinate system. The pointing information must be relevant to the properly displayed image, as indicated by the display orientation keywords LINE_DISPLAY_DIRECTION and SAMPLE_DISPLAY_DIRECTION Epoch and equinox must be indicated where they are relevant, using in-line comments if necessary.

10. Data Files, General

10.1

Data records must be FIXED_LENGTH unless there is a compelling reason to do otherwise.

10.2

Use the most specific available object appropriate to the data. Specifically:

Spectra should use the SPECTRUM object
Time sequences should use the TIME_SERIES object
Inhomogeneous data should use the TABLE object

10.3

The QUBE and all primitive objects should not be used in the main archival data products of the SBN (They may be used in ancillary and support products when necessary). It is preferable to split a single data file into pieces which can be described by the well-supported PDS objects than to retain it in an un- or under-supported format.

10.4

Prefix bytes should be avoided in SBN archive products. For TABLEs, the table definition should either be expanded to include the fields in the row prefix, or the prefix section should be split from the main TABLE and placed in a separate file with its own label and documentation. In IMAGEs, prefix bytes which are not essential to the nature of the image data record should be split into a separate file.

10.5

Large files which are most likely to be accessed by program, rather than by visual inspection, should be individually indexed to assist users in retrieving individual records of interest.

10.6

Each file should contain one and only one object, with the possible exception of a HEADER object, which if present must precede the main data object. Exceptions can be made for publication volumes, but they must be justified.

10.7

UTC time format is strongly preferred. Where only native times are supplied, an effort should be made to supply at least a rough UTC equivalent.

11. Data Files, ASCII Tables

11.1: ASCII files must contain only printing characters, except for the blank space, new line and carriage-return characters (octal codes \010, \012 and \015, respectively).
11.2: All data fields must be separated from adjacent fields by at least one blank space (i.e., "gutter space"), with the exception of fields which are described separately but are logically connected (time fields, for example).
11.3: The first few records in an ASCII TABLE file should contain numeric column labels corresponding to the COLUMN_NUMBER values in the label file. These records are described in the label file as a HEADER object of type COLUMN_LABEL.
11.4: The TABLE data itself may not contain comment or spacing lines, or decorative characters between or around the data fields.
11.5: Numeric fields must be right-justified.
11.6 If one numeric value has a decimal point, all (nonblank) values in that column must have a decimal point.
11.7: Decimal points, whether real or implied, must align in all values of numeric fields.
11.8: Null values in numeric fields must be identified by an appropriate numeric flag value defined in the label. This value must lie outside the normal range of the data. In limited cases a blank field (interpreted as zero) may be acceptable.
11.9: String fields must be left-justified unless there is a compelling reason to do otherwise.
11.10: Record width should be consistent with the projected use of the table. Tables likely to be accessed mainly by visual inspection should be < 150 bytes wide. When necessary, very wide tables should be split into two files, with the identification field(s) being repeated in each part of the file.
11.11: Record format and column definitions in successive records of the table must be identical in archive products. In support files which contain principally a text field and a identifying code (a reference list or note file, for example), it is acceptable to use a flag field (or record count) to indicate continuation records.
11.12: Record lengths must be fixed. Wherever feasible, pad (or trim) records to an even number of bytes.
11.13: All ASCII files must use the combined CR/LF record delimiter.
11.14: Columns indicating a value for year may use only two digits if and only if the appropriate century is included in the COLUMN definition using the OFFSET keyword.

12. Data Files, Binary Tables

12.1: Records in archive products must be fixed length. In the very rare case in which variable-length records can be justified, software must be provided in ANSI standard C to unpack or otherwise extract records from the data file.
12.2: Record lengths must be an even number of bytes. When padding is required, the additional byte(s) may be inserted following whatever field is deemed to be appropriate, but never on a word boundary. These bytes should be set to a hex null (zero) value.
12.3: Binary data should be converted to an ASCII TABLE equivalent for the archive if it seems likely the data will be accessed by visual inspection, provided the size of the file is not prohibitive.
12.4: All integer values must be in Most Significant Byte (MSB) first order. Data received in other formats should be byte- and word-swapped appropriately during ingest.
12.5: Null values must be indicated by a flag value, which must be documented in the label. Null values must lie outside the valid range of the field.
12.6: MAXIMUM and MINIMUM values must be indicated in the label for all fields in which the extrema are not inherently obvious (as they are for, say, an "HOURS" field). These values are necessary to enable a user to verify that he has properly decoded the data record into his home system.
12.7: Fields containing an integer value for year may use implied centuries if and only if the appropriate OFFSET value for the assumed century is included in the label in the corresponding COLUMN definition.

13. Data Files, Images

13.1: Discrete image observations should be in separate files, each with its own PDS label.

14. Data Files, FITS Data

14.1: PDS labels must be detached from the FITS data in SBN archive products. FITS headers must be attached to their data segments in SBN archive products.
14.2: Properly formatted FITS ASCII tables may not be ingested as archival products. FITS ASCII table format requirements conflict directly with PDS ASCII TABLE requirements. SBN will not archive data which does not adhere to a formal standard. [However, the FITS equivalent (properly re-formatted) of a PDS ASCII table may be included in a data product as a service to the community. In this case the FITS file is not the archive product, the PDS-compliant version is.]

20. Catalog Objects, General

20.1

The first keyword in all catalog files must be PDS_VERSION_ID.

20.2

The second keyword in all catalog files must be LABEL_REVISION_NOTE. The contents of this keyword should be in mixed case, and should follow this style:

 LABEL_REVISION_NOTE = "
     24 Nov 1998, A. Raugh      Log of changes made at this time,
                                in sufficient detail to allow a user
                                to determine where substantive changes
                                have been made.

     01 Jan 1999, A. Raugh      Further revision details...
     "

where the name indicates the name of the person who edited the file. LABEL_REVISION_NOTE must be updated when there are significant changes to the contents of the file. It need not be updated for minor format changes or correction of trivial typographical errors.

20.3

All catalog files must end with an "END" statement.

20.4

REFERENCE objects corresponding to the REFERENCE_KEY_IDs listed in the catalog files must be in a separate file. REFERENCEs are generally collected into a single file spanning all datasets in a given volume or review set.

20.5

ID fields may not be identical to their corresponding NAME fields. For example, INSTRUMENT_NAME must not be identical to INSTRUMENT_ID. IDs are intended to be brief (< 6 characters) acronyms; NAME fields are intended to provide full, descriptive titles (up to 60 characters).

20.6

All IDs mentioned in any catalog files submitted to the SBN must be accompanied by the corresponding catalog file for the ID referenced. This may be a copy of the catalog file already in the PDS archive, if one exists.

21. DATA_SET Objects

21.1

The value for DATA_SET_ID may not contain the underscore character. This value must be determined using the rules laid out in the PDS Standards Document.

21.2

All DATA_SET_INFORMATION objects for data sets to be included in the on-line archive must include a DATA_SET_LOCAL_ID keyword. This ID should be short (< 6 characters or so), must consist entirely of uppercase letters and numbers and should be as mnemonic as possible to the DATA_SET_NAME. This ID is used to name the dataset's directory tree and in the formulation of PRODUCT_ID for its associated data files. It must be unique across the SBN archive holdings.

21.3

PRODUCER_FULL_NAME must contain the name of the person responsible for the major work done in producing the formatted SBN archive product. Production of the archive product includes generating data labels and catalog files, verifying data file formats and collecting documentation. It may be a member of the SBN or it may be a data supplier who submitted data already largely in PDS format. Caveats to this credit and to the production process should be noted in the DATA_SET_DESC prose.

21.4

All DATA_SET_INFORMATION objects should contain an OBSERVER_FULL_NAME keyword where appropriate. The value of this keyword should be the full name of the person responsible for conducting the observations comprising the main data (the principal investigator, for example); or, in the case of compilation catalogs, the name of the person responsible for collecting the included observations. In the case of a compiler, include an in-line comment after the keyword value indicating that this is a compiler. For example:

  OBSERVER_FULL_NAME = "CLIFFORD CUNNINGHAM"   /* Compiler */

OBSERVER_FULL_NAME should not contain more than one name. If there is no single observer or compiler, omit the keyword. More complicated relationships between observer/compiler and the data should be detailed in the DATA_SET_DESC prose.

21.5

The DATA_SET_DESC prose must contain the following headings:

Data Set Overview: This section must come first and should contain a brief (about 250 words) summary of the contents and purpose of the dataset.
Data: A brief run-down of the data files included

Media/Format: Boiler plate text describing the primary format of the product. For example, for the on-line asteroid catalogs this section typically looks like this:

  Media/Format                                                                
  ============                                                                
  This dataset is released in the form of ASCII files which may be            
  stored on disk or other magnetic medium and which may be                    
  distributed by ftp, email, real-time access by remote login, or by          
  whatever means is most convenient.

Other sections may be included as needed, anywhere following the "Data Set Overview" section. For example, descriptions of the various coordinate systems and standards mentioned in the data labels should be included under the heading Coordinate Systems. The "Media/Format" section generally comes last.

21.6

The CONFIDENCE_LEVEL_NOTE prose must contain at least a "Review" section with peer review status and schedule. This must be updated during the lien resolution process to indicate that the dataset passed review. The previous text written in anticipation of the review may be deleted once the review and lien-correction are complete.

21.7

The DATA_SET_UPDATE_PERIOD keyword should be included in the DATA_SET_INFORMATION object for all datasets which are expected to be updated on a regular basis. The value is in years. When a dataset is expected to be static, or the availability of updates is not assured, this keyword should be omitted.

22. DATA_SET_COLLECTION Objects

23. INSTRUMENT Objects

24. INSTRUMENT_HOST Objects

25. MISSION Objects

26. REFERENCE Objects

26.1

All REFERENCE objects for a volume or review set are included in the same reference catalog file. They should not be duplicated elsewhere.

26.2

REFERENCE_KEY_ID values must be unique across the entire PDS. Values must follow the specifications in the PDS Standards Reference strictly. Once created, REFERENCE_KEY_IDS cannot be changed, so create them carefully.

26.3

REFERENCE_KEY_IDs may not be used as a substitute for a standard citation in the text of descriptive keywords. They may be included after the citation in square brackets, if desired. For example:

...as described in A'Hearn, et al. (1996) [AHEARNETAL1996].  The...

26.4

REFERENCE objects (and REFERENCE_KEY_IDs) should be created only for those references which are essential to understanding the data presented. All other references to supplementary material should be listed in standard publication style in the DATA_SET_DESC prose in the DATA_SET catalog file.

26.5

REFERENCE_DESC test must follow this style:

A'Hearn, M.F. and R.L. Millis, 1980.  Abundance correlations among
         comets. Astronomical Journal, 85, 1528-1537.

First author is listed surname first, then initials.
Subsequent authors are listed initials first, then surname.
Separate authors' names with a comma, except for the final name which is prefaced by "and".
Year of pulication follows the author list, separated by a comma and followed by a period.
Title follows the year, ended by a period.
Publication name, editors (in parentheses) if any, volume/number and pages come next, each field separated by commas and ending with a period.

26.6

Do not create a REFERENCE object for personal communications, World Wide Web sites, or any document which does not exist in a permanent, generally accessible form. If necessary, create or capture a version of the communication, Web page, etc. and store it permanently in the associated "document" directory of the archive volume, then reference this permanent copy. Do NOT violate copyright to accomplish this. You must get the copyright holder's permission to reprint any text. Note that in the case of papers published in reviewed journals, the author is most often no longer the legal copyright holder.

26.7

For names, titles and other text from non-Latin alphabets, use the PDS standard style sheet on file for that language to transliterate.

27. TARGET Objects

27.1: All objects mentioned as the value of a TARGET_NAME keyword must have TARGET catalog objects included in the delivery. Existing objects may be used when available.
27.2: Target descriptions should be succinct. They should provide known physical parameters, distinguishing characteristics and alternate designations. For example, examining the TARGET description should make it possible for a user to immediately determine if the object "Halley" mentioned in a data label is the comet 1P/Halley or the asteroid (2688) Halley. They should not contain information specific to a single mission.

28. VOLUME Objects

28.1: All volumes must include a local copy of the Planetary Science Data Dictionary which contains definitions for all keywords appearing on the volume as they were known to the format and verification tools which generated the data and volume. This may be the full PSDD or a subset. It may include keywords with a status of "PENDING" in cases where the keyword was used in the data in anticipation of its being approved by the PDS.
28.2: In general, each DATA_SET_ID on a publication volume should have its own directory structure. Files belonging to different datasets (i.e., with different DATA_SET_IDs), should not be mixed in the data directories without reasonable justification.
28.3: Supplementary data (raw records, derived tables, etc.) must be in a separate directory from the main archival data. This data may be in the same directory tree but at, say, a lower level than the main data.
28.4: On permanent volumes (CDROM, DVD, etc.), each file will appear in exactly one archive directory. That is, no logical links, overt or otherwise, should point up, down or laterally in the part of the volume containing the archive data files.

31. DOCUMENT Files

31.1: All DOCUMENT objects must include a DATA_SET_ID keyword containing the list of DATA_SET_IDs for which the document is relevant.
31.2: Each logical format of a document must have its own label, to eliminate the inherent ambiguity in the current DOCUMENT object. A logical format may consist of more than one file (HTML plus graphics, for example).
31.3: Each document label must contain a unique DOCUMENT_NAME value. Include version numbers or file formats in the DOCUMENT_NAME to distinguish between versions or logical forms of the same document, as needed.

50. Identification Fields, General

50.1: Standard NAME values and column DESCRIPTIONs must be used for all asteroid and comet identification fields in SBN archive products. These are listed below in sections 51 and 52, respectively. Identification fields may occur in any order, but they must appear before all other data fields.
50.2: Each identification column must contain only one type of identification. If the given identification is not available for a particular record, the field should be left blank. A separate COLUMN must be provided for each type of identification present in the file, regardless of the number of records which contain that type of identification.
50.3: There must be at least one definitive identification for each small body data record.
50.4: Identification fields need only be as wide as the widest value occuring in the file.

51. Asteroid Identifications

51.1

Asteroid identifications should be listed in data records in this order:

Minor Planet Number
Asteroid Name
IAU Asteroid Principal Provisional Designation
(and following) Other designations

Fields which are completely blank in a dataset may be omitted. Never mix designations of the first three types from the above list in a single column. Never put more than one designation (even of the same type) in a single column of a record.

Names, definitions and standard DESCRIPTION field values for the primary asteroid identifications follow.

51.2

MINOR PLANET NUMBER: The official catalog number assigned by the Minor Planet Center. Currently five digits are sufficient to hold any asteroid number.

DESCRIPTION = "The minor planet number assigned by the Minor Planet Center once the orbit of an asteroid has been firmly established."

51.3

ASTEROID NAME: The IAU approved name of the object

DESCRIPTION = "The name adopted by the IAU for this object."

51.4

IAU ASTEROID PRINCIPAL PROVISIONAL DESIGNATION: A year followed by 2 letters and 1-3 digits. Asteroids frequently receive several provisional designations before they are numbered, but one of these will be chosen as the principal designation. Note that principal provisional designations of asteroids frequently change, and often more than once.

DESCRIPTION = "The principal provisional designation is the preferred identification assigned by the Minor Planet Center to asteroid discoveries and recoveries. It consists of the year of discovery/recovery, followed by two uppercase characters indicating the part of the year of discovery, followed by a sequential number indicating the order of discovery within that year fraction."

51.5

Wherever possible, provisional asteroid designations supplied with a dataset should be compared to the current ID database and the new name, catalog number, or principal provisional designation should be added to the file. The original provisional designation should be left in tact.

52. Comet Identifications

52.1

Comet identifications should be listed in data records in this order:

Periodic Comet Number
Comet Type
Comet Name
IAU Comet Designation
Comet Fragment Identifier, if any (occurs rarely)
IAU Asteroid Designation, if any (occurs rarly)
Old-Style IAU Provisional Designation
Roman Numeral (Perihelion Order) Designation

Omit fields which are completely blank in any given dataset. Asteroid identifications associated with comets should be listed in a separate column (i.e., not with the IAU comet designation).

Names, definitions and standard DESCRIPTION field values for the comet identifications follow.

52.2

PERIODIC COMET NUMBER: a 3-digit integer used to identify short-period comets.

DESCRIPTION = "Periodic comet number, or blank if this is either not a short-period comet or has not yet been numbered."

52.3

COMET TYPE: one upper-case character object type, often prefixed to the comet name with a slash (/).

DESCRIPTION = "A one-character code indicating the type of comet:

When this field is non-blank, it is separated from the next field by a slash (/) character."

52.4

COMET NAME: The surname(s) of up to three co-discoverers, connected by hyphen (-) characters. This should always be the full comet name, never an abbreviation (that is, "Giacobini-Zinner" rather than "G-Z", "Shoemaker-Levy 9" not "SL9", etc.).

DESCRIPTION: "Full name of the comet"

52.5

IAU COMET DESIGNATION: The discovery designation assigned by the Central Bureau for Astronomical Telegrams. This requires at least 6 characters and may often require 7 characters. For periodic comets with more than one discovery designation, the IAU CBAT will designate one of these as the principal IAU designation. This is the ID which should be used.

DESCRIPTION = "The discovery designation assigned by the Central Bureau for Astronomical Telegrams, consisting of the four-digit year of discover, followed by a blank, followed by a capital letter indicating the half-month of the discovery. When more than one comet is discovered during a single half-month, an additional sequential number is appended to the letter."

52.6

COMET FRAGMENT IDENTIFIER: A single uppercase character, usually appended to the IAU designation (comet or asteroid) with a hyphen (-).

DESCRIPTION = "A single character used to differentiate between pieces of a compound objects"

52.7

OLD-STYLE IAU PROVISIONAL DESIGNATION: a year followed by a lower-case character and possibly a digit.

DESCRIPTION = "Old-style IAU provisional designation, consisting of the year of discovery, followed by a single lower-case letter indicating the order of discovery, optionally followed by a digit. When letters were exhausted in a given year, the alphabetic sequence was restart with an appended '1'. So, for example, 1991a1 was discovered immediately after 1991z."

52.8

ROMAN NUMERAL DESIGNATION: a year followed by a roman numeral

DESCRIPTION = "Old-style IAU perihelion designation, consisting of the year in which the comet reached perihelion, followed by a space, followed by a roman numeral (in uppercase) indicating the sequential order in which the comet passed perihelion among all comets passing perihelion that same year."

52.9

Wherever possible, when only one designation is provided for comet objects, the others should be supplied. This is especially true when the only identifications supplied are obsolete forms (old-style IAU provisional or Roman numeral designations) or names, which are not definitive.

SBN ODL Style Sheet Index

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A

Alignment of "=", 1.2
ASCII data: character fields, 11.9
column labels, 11.3
field separators, 11.2
numeric fields, 11.5 - 11.7
record length, 11.10 - 11.12
PDS TABLE format conflict with FITS TABLE extension, 14.2
valid characters, 11.1
Asteroid identifications, 51: formats, 51.2 - 51.6
order in data records, 51.1
Auxiliary COLUMN definitions, 3.3"

B

Binary data, 12: converting to ASCII, 12.3
Blank padding between columns (gutter space) in ASCII tables, 11.2
BYTES, 3.1

C

Carriage-control: in ASCII files, 11.1, 11.13
Case in keyword values, 1.6, 1.7
Catalog files: REFERENCE objects, 20.4
required for all IDs, 20.6
required keywords, 20.1 - 20.3
CELESTIAL_NORTH_CLOCK_ANGLE, 4.2
Character data, 11.9
Coded values in data, 3.6
COLUMNs: auxiliary definitions, 3.13
gutter space, 3.14, 11.2
ordering of definitions, 3.12
overlapping definitions, 3.13
required keywords, ASCII tables, 3.1
required keywords, binary tables, 3.3
UNIT, 3.5
Column labels, 3.11, 11.3
COLUMN_NUMBER, 3.1, 3.3, 3.12
Comet identifications, 52: formats, 52.2 - 52.8
order in data records, 52.1
Comet type, 52.3
Comments, 1.8, 11.4
Compilations: crediting compiler via OBSERVER_FULL_NAME, 2.6, 21.4
CONFIDENCE_LEVEL_NOTE, 21.6
Coordinate System description, 21.5

D

DATA_SET_ACRONYM: in PRODUCT_ID, 2.2
DATA_SET_COLLECTION object, 22
DATA_SET_DESC, 21.3-21.5: contents, 21.5
DATA_SET_ID, 21.1: volume organization of, 28.2
DATA_SET_INFORMATION, 21.2, 21.4, 21.7
DATA_SET_LOCAL_ID, 21.2
Data Set Overview, 21.5
DATA_SET_UPDATE_PERIOD, 21.7
DATA_TYPE: numeric types in ASCII tables, 3.2
numeric types in binary tables, 3.4, 12.4
Decimal points, 11.5, 11.6
DERIVED_MAXIMUM, 3.10
DERIVED_MINIMUM, 3.10
_DESCRIPTION (or _DESC) keywords: mixed case in, 1.6
required, 2.11
Detached PDS labels, 14.1
DOCUMENT objects, 31.1: what to label, 31.2
DOCUMENT_NAME use, 31.3

E

END statement, 20.3
END_OBJECT, 1.4, 2.9
Equal sign (=): alignment, 1.2

F

File names: case of, 2.4
in pointer values, 2.4
in PRODUCT_ID, 2.2
FITS files: attached headers, 14.1
FITS (ASCII) tables, 14.2
Flag values, 11.7

G

Gutter space between columns in ASCII tables, 3.14, 11.2

H

HEADER objects, 10.6: with TABLE data, 3.11

I

IDs (for archive objects), 20.6
_ID keywords, 20.5
Identification fields, 50
IEEE format real numbers, 3.4
IMAGEs, 13.1: _PREFIX_BYTES, 10.4
display oreintation keywords, 4.1, 4.2
orientation keywords, 4.2
Indices, 10.5
INSTRUMENT object, 23
INSTRUMENT_HOST object, 24
INVALID_CONSTANT, 3.8
ITEMS, 3.7

J

K

Keywords: indentation of, 2.9
local data dictionary, 28.1
preferred order in product labels, 2.7, 2.8
Keyword values: case in, 1.6
case of, 1.9
quotes, 1.5
underscores in, 1.7

L

LABEL_REVISION_NOTE: format, 20.2
in product labels, 2.5
in catalog files, 20.2
Labels (Product Labels), 2: change logging, 20.2
detached, 14.1
one label - one data file, 2.12
self-contained, 2.13
LINE_DISPLAY_DIRECTION, 4.1, 4.2

M

MAXIMUM: in ASCII files, 3.9, 3.10
in binary files, 12.6
Media/Format (section of Data Set Overview), 21.5
MINIMUM: in ASCII files, 3.9, 3.10
in binary files, 12.6
MISSING_CONSTANT, 3.8
MISSION object, 25

N

NAME, 2.10
Names, transliterating from non-Latin alphabets 20.5
_NOTE keywords: mixed case in, 1.6
NULL values, 11.7, 12.5

O

Objects: DESCRIPTION, 2.11
indentation, 2.9
keyword location, 1.3
NAME, 2.10
selecting, 10.2, 10.3
Object identifications: asteroids, 51
comets, 52
OBSERVER_FULL_NAME: in product labels, 2.6
in DATA_SET_INFORMATION object, 21.4
Orientation keywords in IMAGEs, 4.2
Overlapping COLUMNs, 3.13

P

Padding records, 12.2
PDS_VERSION_ID, 2.3, 20.1
Peer review logging, 21.6
Personal communications, citing 26.6
Planetary Science Data Dictionary (PSDD), local copy on physical volumes, 28.1
Pointers: file names in, 2.4
Pointing information, 4.2
_PREFIX_BYTES, 10.4
Primitive objects, 10.3
Principal investigator: Identified in OBSERVER_FULL_NAME, 2.6, 21.4
PRODUCER_FULL_NAME, 21.3
PRODUCT_CREATION_TIME, 1.1
PRODUCT_ID, 2.2, 21.2
Product labels, 2: See: Labels
PRODUCT_NAME, 1.6
Prose keywords: mixed case in 1.6

Q

QUBE object, 10.3
Quotes: around keyword values, 1.5

R

Record lengths, 10.1, 11.10: even byte count, 11.12, 12.2
in binary files, 12.1, 12.2
REFERENCE objects, 26: collected in a separate file, 20.4, 26.1
personal communications, 26.6
World Wide Web sites, 26.6
when to create, 26.4
REFERENCE_DESC style, 26.5
REFERENCE_KEY_ID, 26.2 - 26.4: as a citation supplement, 26.3
immortality, 26.2

S

SAMPLE_DISPLAY_DIRECTION, 4.1, 4.2
SFDU labels, 2.1
Small body identification fields: See: Identification fields
START_BYTE, 3.1
Supplementary data on physical volumes, 28.3

T

TABLEs: column labels, 11.3 label files, 3
PDS ASCII vs. FITS TABLE, 14.2
_PREFIX_BYTES, 10.4
TARGET objects, 27: Contents of description, 27.2
Time data, 10.7: year values, 11.14, 12.7
Transliteration, 26.7

U

Underscores: in DATA_SET_ID, 21.1
in keyword values, 1.7
UNIT, 3.5
UTC time data, 10.7

V

Vectors in table columns, 3.7
VOLUME objects, 28
Volumes (physical volumes): directory structure, 28.2, 28.3
local data dictionary, 28.1
logical links prohibited in, 28.4

W

Web sites, citing, 26.6

X

Y

Year data, 11.14, 12.7

Z

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Contents

SBN ODL Style Sheet Index