Format Description Document
Format Description Document Properties
Format Identification and Description
Local Use
Sustainability factors
Quality and functionality factors
The File type signifiers section documents some of the signifiers that may be used by automated systems to identify a format or the data it contains.
Notes (General and History)
Format Specifications
Useful References
Identifier for the format and its description.
Title for the format document
Mnemonic abbreviation used to refer to the format.
Format Description Properties
A single genre entry.
A single primary genre entry accompanied by one or more subsidiary-genre entries.
One or more genre entries, none of which is of greater primacy than the others.
General type of format, e.g., file format, bitstream encoding.
Date description last updated.
Full [fully realized draft], Partial [draft in progress], Partial (low priority for LC) [format not expected to impact LC, no full draft contemplated], and Preliminary [placeholder for FDDid, lacking information for all or most sustainability, quality, or functionality factors]
Format Identification and Description
Name of the format. Formal name, if the format has been established by a Standard Setting Organization (SSO), which include both Standards Developing Organizations (SDO) like ANSI and the various bodies it accredits in the US, or trade organizations, consortia, or other groups. For formats established by corporations, the common or colloquial full name is provided. Common names are also provided for standardized formats, when the formal name excludes colloquial elements.
Brief characterization of the format.
Shorter Description of the Format
Indication of how the format is generally used during the content life cycle, e.g., by creators or authors (initial state), by distributors, publishers, or archives (middle state), or as delivered to endusers (final state).
Indications of the relationships between this and other formats, using statements of the types listed in the following rows. Intended to mesh with the work of the GDFR (Global Digital Format Registry).
GDFR relationship is has_Restriction or possibly is-Extension-of
GDFR relationship is is-Restriction-of
Inverse of containment. Use only when it adds value for human reader, for example because format being described has an important primary use, or when no formats that may contain this format have been described in FDDs.
Use component relationships when dealing with a group of files that coexist and function together as a single resource. Component files will often live in the same directory and have related names.
Inverse of may or must have containment
Used to indicate that an XML-based format is defined via W3C XML Schema or Relax NG, for example.
As used in GDFR for relationships that are neither strictly extensions or restrictions of each other. E.g., BWF is Modification of WAVE)
Use only as inverse of Modification_of. As used in GDFR for relationships that are neither strictly extensions or restrictions of each other. E.g., WAVE has modified version BWF. Use only when it adds value for human reader, e.g., because related format is particularly important and might be expected to be described as a subtype.
As used in GDFR. B is an extension of A if all instances of A are also instances of B, but not all instances of B are instances of A. Technically equivalent to Has_subtype, but more intuitive when B follows A chronologically. Use in preference to Has Earlier Version if the GDFR definition fo rextension is satisfied. If a format has a robust extensibility mechanism, new versions that use that mechanism (without making other changes) will be extensions of a base format.
As used in GDFR. Inverse of Extension_of. Use in preference to Has Later Version if GDFR definition of extension is known to be satisfied.
Preferred to Version of
Preferred to Version of
Use when more precise relationship (e.g. subtype) does not apply and version relationship is non-temporal (e.g., geographical) or when sequence is unknown.
From GDFR, for semantic or syntactic equivalence, e.g., TIFF (little-endian) is syntactically equivalent to TIFF (big-endian).
Significant *technical* resemblance not meeting formal requirements of GDFR relationship types.
Candidate for new type of relationship. Label for typeOfRelationship to be provided in explanatory comment
Significant non-technical relationship. To be accompanied by an explanatory comment.
Local Use
Report of actual practice at the Library of Congress.
Provisional Library of Congress format preference. In some cases, the statement will indicate that the format at hand is preferred; in others, the statement will identify a different format as preferred; in still others, no preference will be known.
Sustainability factors
Level of available technical information about the format, including documentation that requires purchase. Typical statements of level include open standard, fully documented, partially documented, and little documentation. The statement of level is followed by the identification of source or developer
Citation of specifications or other documentation. For standardized formats, identification of relevant standard, generally by assigned number. A few individual documents are cited in this location; if the list is long (as it is for many multipart ISO/IEC standards), the complete list is provided in the Format specifications or Useful references sections at the bottom of the page. All documents cited in the table portion of the Format Description are cited again in Format specifications or Useful references below.
Assessment of the degree to which this format is implemented and employed
Statement regarding patents and/or licensing.
Statement regarding the nature of the encoding and/or bitstream, suggestive of the ease with which rendering tools may be obtained or built.
Statement regarding the degree to which the format supports the inclusion of metadata (descriptive, administrative, and structural).
Statement regarding the need for external software or hardware
Support by this format for elements that protect intellectual (or other) property
Quality and functionality factors
Normal Rendering. Supports on-screen viewing and printing to paper of raster, vector, and other two-dimensional images. For images with sufficient spatial resolution or vector capabilities, includes the ability to zoom in to study detail, to scale images to display at different sizes or on devices of different resolution, and/or the ability to produce publication quality output.
Clarity (support for high image resolution). Does this format support the representation of pictures that would be deemed high resolution when viewed by experts or repurposed for a very high quality application?
Color maintenance (support for color management). Refers to the degree to which the color gamut represented in a given image can be managed and maintained through various outputs or migrations; for example, via support for color encoding in different colorspaces and the metadata needed by color management systems, such as the inclusion of a color map for indexed-color files or an ICC profile for the capture device.
Support for vector graphics, including graphic effects and typography. Refers to the support within the format for scaleable shapes, labels, legends, and other vector-graphic features. Also to the degree to which the format supports the use of shadows, filters or other effects as applied to fill areas and text, offers levels of transparency, and manages the specification of fonts and patterns.
Support for multispectral bands. Refers to support for multiple spectral bands employed to support scientific analysis, in contrast to widely adopted color-model (colorspace) configurations oriented toward human perception, e.g., RGB or CMYK.
Functionality beyond normal rendering
Normal rendering
Clarity (support for high image resolution)
Functionality beyond normal rendering
Normal rendering
Fidelity (support for high audio resolution)
Support for multiple channels (including note-based, e.g., MIDI)
Support for downloadable or user-defined sounds, samples, and patches
Functionality beyond normal rendering
Normal rendering
Support for integrity of document structure and navigation
Support for integrity of layout, font, and other design features
Support for rendering for mathematics, formulae, diagrams, etc.
Functionality beyond normal rendering
Normal rendering
Documentation of harvesting context
Efficiency at scale
Support for stewardship
Functionality beyond normal rendering
Normal functionality. The basic functionality for a dataset format is to provide a structured representation of numeric or character-based values together with information that permits automated manipulation of the structure and the representation in order to perform calculations and transformations based on the values.
Support for software interfaces for access to data within a dataset. Refers to support for standard, widely available, or community-specific APIs, software toolkits, or software libraries, particularly for extracting data subsets, data manipulation/transformation, data aggregation, or domain-specific functionality.
Support for documenting data quality or provenance. Refers to support for documentation in textual or, preferably, in structured machine-processable form (e.g., in a well-known XML schema).
Functionalities beyond normal and not covered by other factors.
Normal functionality. The basic functionality for a GIS format is the ability to locate information in relation to the surface of the earth, either both horizontally and vertically or horizontally with height or depth implicit. This geo-referencing may locate an entire resource (e.g. an image) or individual data values within a resource. Spatial data is usually stored as coordinates and topology or as georeferenced images and is data that can be mapped, accessed, manipulated or analyzed.
Support within the format for GIS-specific metadata, in a machine-processable form, particularly in a form that satisfies standards or community practices in a way that contributes to interoperability. Important characteristics to be recorded in metadata include: projection, scale, datum for coordinates. For certain categories of GIS files, other characteristics may be significant, e.g. percentage of cloud cover in satellite images. Note that support for metadata documenting data quality and provenance is covered in a Dataset factor.
Support for grids. Refers to support for recording gridded data, i.e. where one or more data values are associated with each rectangular cell in a grid defined by geographic coordinates. Note that raster images can function as pixel-based grids.
Functionalities beyond normal and not covered by other factors.
This section documents some of the signifiers that may be used by automated systems to identify a format or the data it contains.
Name extensions generally used in Windows, UNIX, and other environments. From various sources.
When Possible, from the IANA MIME Media Types site; otherwise (and in addition) from other sources.
The first bits in a file, used to identify the type of file, often associated with Unix and its derivatives. The most frequent sources for information are Gary Kessler's File Signatures and Filext.com
This is the list of values after review in September 2008. In addition to a few additionss, a few modifications were made to reduce redundancy, provide context or clarification. Not intended to be sufficient to build an identification tool with fine granularity.
Notes (General and History)
Additional information, often an extension of description in the first section above.
Information about the history of the format.
Format Specifications
Useful References
Use for Web sites and Web pages that are not equivalent to a single coherent document with a title intended to be persistent. For persistent documents, use "citation" element.
Use for Web sites and Web pages that are not equivalent to a single coherent document with a title intended to be persistent.
Use for single Web sites and Web pages that are not equivalent to a single coherent document with a title intended to be persistent. NOTE: CHOICE between urlReference and urlGroup -- if you open both, you will need to delete one to create valid FDD.
Group of related url elements with introductory notesText that covers them all. NOTE: To use urlGroup instead of urlReference, you may need to delete an empty urlReference created by default.
Use for documents published with clear intent to be persistent and persistently citeable in print, online, or both. Allows tagging of title, author, etc. Can include URL and link. Can be an individual citation or a group of related citations (without further nesting).
Use details element and rel attribute to tag author, title, etc, within citation for possible future reference linking through OpenURL.
Use details element and rel attribute to tag author, title, etc, within citation for possible future reference linking through OpenURL.
Use details element and rel attribute to tag title, standard number, etc, within citation for possible future reference linking through OpenURL.
Group of related document citations with introductory notesText
Use details element and rel attribute to tag title, standard number, etc, within citation for possible future reference linking through OpenURL.
Use details element and rel attribute to tag author, title, etc, within citation for possible future reference linking through OpenURL.
Use details element and rel attribute to tag author, title, etc, within citation for possible future reference linking through OpenURL.
Use either a sequence of separate values for the signifier or one of the enumerated string values for sigValueNA (to say something about signifier values without actually providing one or more)