Format Working Group

Review of RFC2413

Date: 1999-03-05

Status: Under Discussion by DC-TAC

Proposed Definition

  Name:        Format
  Identifier:  Format
  Definition:  The media type or dimensions of the resource
  Obligation:  Optional
  Datatype:    Character String
  Maximum
   Occurrence: Unlimited
  Comment:     Format may be used to determine the software, hardware or
               other equipment needed to display or operate the resource.
               The use of controlled vocabularies (for example the list of
               Internet MIME Types [1]) is encouraged.
               Examples of dimensions include size and duration.

  [1] http://www.isi.edu/in-notes/iana/assignments/media-types/media-types

Summary of changes

• Adoption of ISO 11179 representation
• Separation of "definition" from "comment"
• 'Data format and, optionally, dimensions' replaced by 'data format or dimensions'
• 'Data format' replaced by 'media type'
• Improved clarity of "comment"
• Explicit reference to Internet MIME Types in "comment"

Issues List

Several issues have been raised during the review of the RFC-2413 definition of the Format element.

Issue 1: Should 'dimensions' be part of the scope of Format

Proposal - that 'dimensions' are removed from the scope of the Format element.

Arguments in favour:

• Placing 2 very different values into 1 element is confusing and illogical.

Arguments against:

• The current definition includes dimensions. Changing the definition may cause problems for existing implementations.
• Format is the only appropriate element for dimensional information. If dimensions aren't within the scope of Format, then they aren't within the scope of DC.

Issue 2: 'data format AND, optionally, dimensions' vs. 'data format OR dimensions'

Proposal - the current wording of the definition 'data format and, optionally, dimensions' be changed to 'data format or dimensions'.

Arguments in favour:

• The current definition (using AND) implies that dimensions can only be given in addition to data format. For some resources, e.g. physical objects, it may only be appropriate to give dimensions.
  A definition using OR, implies that it is equally appropriate to give data format or dimensional information.
• A definition using AND implies that both bits of information should be given in the same element value.
  A definition using OR, encourages the use of repeated Format elements for data format and dimensions, rather than putting multiple bits of information in the same element value.
• It is illogical to refine Format into separate 'data format' and 'dimensions' FormatTypes if it is defined as 'data format AND, optionally, dimensions'. Refinement (i.e. qualification) is only logical if the definition uses OR.

Arguments against:

• Changing the definition from 'data format AND, optionally, dimensions' to 'data format OR dimensions' changes the focus of the format element - it gives equal weight to dimensional information. Therefore, the element is no longer the 'format' element - it is now an element called 'format and dimensions'.

Issue 3: 'medium' or 'media type' vs. 'data format'

Proposal - 'data format' in the current definition be replaced by 'medium' or 'media type'.

Arguments in favour:

• 'Media type' is the terminology used in the Internet MIME Type RFCs. It also seems appropriate for many physical objects.
• The current definition uses the word 'format' to define the term 'Format'. This is bad practice.

Arguments against:

• The word 'type' in 'media type' may cause confusion with the Type element.

Issue 4: Should the element name be changed to 'Format and Dimensions'?

Proposal - Format be renamed 'Format and Dimensions'.
(Note that this proposed change does not alter the current label (the ISO 11179 Identifier), 'Format').

Arguments in favour:

• By changing 'and' to 'or' in the definition (see issue 2 above) we have made a slight change to the focus of the Format element. 'Format and Dimensions' more accurately reflects the definition of the element.

Arguments against:

• Dimensions have been within the scope of Format for some time without apparent confusion. Therefore this change may be unnecessary.

Issue 5: Should the Getty AAT be added as an example of a controlled vocabulary?

Proposal - the Getty AAT should be added as an example of a controlled vocabulary.

Arguments in favour:

• Referring to AAT emphasisies that the list of MIME types is not the only source of values for Format.
• Referring to AAT emphasises that Format (and DC) can be used to describe non-digital resources.

Arguments against:

• The AAT contains terms that may be appropriate for the Type element - including it in the "Comment" for Format may be confusing.

Issue 6: Should the Comment explicitly mention 'delivery format'?

Proposal - a phrase should be added to the comment to emphasise that the Format is that in which the resource is delivered.

Arguments in favour:

• Such a phrase might help to emphasise the difference between Format and Type.

Existing RFC-2413 Definition

Format
Label: "Format"

The data format and, optionally, dimensions (e.g., size, duration) of the resource. The format is used to identify the software and possibly hardware that might be needed to display or operate the resource. For the sake of interoperability, the format should be selected from an enumerated list that is currently under development in the workshop series.

References

ISO 11179 Parts 1-6, Specification and Standardization of Data Elements
<URL:ftp://sdct-sunsrv1.ncsl.nist.gov/x3l8/11179/>

IANA Registered Media Types
<URL:http://www.isi.edu/in-notes/iana/assignments/media-types/media-types>

The Art & Architecture Thesaurus
<URL:http://www.ahip.getty.edu/aat_browser/titles.html>