Filling Out the File Area Observational Supplemental Classes

From The SBN Wiki
Revision as of 12:19, 23 March 2016 by Raugh (talk | contribs) ()
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The <File_Area_Observational_Supplemental> class is nearly identical to the <File_Area_Observational>. Use it if you have data that is in a separate file from the observational data structures, but should usually be included with the observational data when sent to a user or incorporated into an interface. (This doesn't often happen with SBN data, but may include, for example, reduced-resolution versions of the observational data for particularly large or cumbersome data objects.)

For additional explanation, see the PDS4 Standards Reference, or contact your PDS node consultant.

Note that in the PDS master schema, all classes have capitalized names, attributes never do.

<File>

This class is handled identically in all File_Area_* classes. It is described in detail on the Filling Out the File Class page.

Data Structures

All the data structures described on the Filling Out the File Area Observational Classes page are also valid in this supplemental class. In addition, the following data structures are at least technically available. Their structures are rather simple and can be read from either the Information Model, the Data Dictionary or the schemas fairly easily.

<Encoded_Binary>

Do not use this structure. The description of the structure indicates that it should not actually be allowed in an observational product.

<Encoded_Byte_Stream>

Don't attempt to use this without consulting your PDS contact first. This generic class would be used to describe files that are encoded (as opposed to being, for example, plain text) to some standard. The standard must be accepted by PDS for the intended purpose before you can use this structure.

<Encoded_Header>

This class is used to describe a header - some string of descriptive bytes generally preceeding the data of primary interest - that must be somehow decoded before it can be understood. Such a header might contain packed data values, for example. The encoding format must be one on the list of accepted formats if the data are headed for the archive.

<Encoded_Image>

Use this structure for things like JPEG or PNG versions of the observational image data (full or reduced resolution). The encoding format must be one designated by PDS as acceptable for browse versions, or similarly, for archival products.

<Parsable_Byte_Stream>

As with the <Encoded_Byte_Stream>, this is a generic class for file formats that consist of unencoded bytes - like delimited table files - where parsing rules must be supplied in order to read the file into programmatic memory structures. As before, the parsing rules must be recognized by PDS as a suitable standard before they can be invoked in this structure.

<Stream_Text>

This data structure appears to be defined as any string of "text" bytes. It should be avoided until and unless it is more specifically defined.

On the whole, if you have free-format descriptive text relevant to an observational product, it more than likely should either be in the label in one of the many available <comment> fields, or it should be formally ingested as a document product and referenced via the <Reference_List> class.