Type Element Working Draft, 1998-10-23

The Dublin Core™ Resource Type (DC.Type) element is used to describe the category or genre of the content of the resource. For the sake of interoperability, the primary value should be selected from the enumerated list presented here. Values for DC. Type selected from these lists will be used without annotation or qualification in simple Dublin Core™.

• text
• image
• sound
• dataset
• software
• interactive
• event
• physical object

These can be defined and used as follows:

text

  <dd>resources in which the content is primarily words for
  reading. For example - books, letters, dissertations, poems,
  newspapers, articles, archives of mailing lists. Note that
  facsimiles or images of texts are still of the genre
  <em>text</em>.</dd>

  <dd> </dd>

  <dt><em>image</em></dt>

  <dd>the content is primarily symbolic visual representation
  other than text. For example - images and photographs of
  physical objects, paintings, prints, drawings, other images
  and graphics, animations and moving pictures, film, diagrams,
  maps, musical notation. Note that image may include both
  electronic and physical representations.</dd>

  <dt><em>sound</em></dt>

  <dd>the content is primarily audio. For example - music,
  speech, recorded sounds.</dd>

  <dt><em>dataset</em></dt>

  <dd>structured information encoded in lists, tables,
  databases, etc., which will normally be in a format available
  for direct machine processing. For example - spreadsheets,
  databases, GIS data, midi data. Note that unstructured
  numbers and words will normally be considered to be type
  <em>text</em>.</dd>

  <dt><em>software</em></dt>

  <dd>computer programs in source or compiled form which may be
  available for installation non-transiently on another
  machine. For software which exists only to create an
  interactive environment, use <em>interactive</em>
  instead.</dd>

  <dt><em>interactive</em></dt>

  <dd>resources which require interaction from the user to be
  understood, executed, or experienced. For example - forms on
  web pages, applets, multimedia learning objects, chat
  services, virtual reality.</dd>

  <dt><em>event</em></dt>

  <dd>non-persistent, time-based occurence. Metadata for an
  event provides descriptive information that is the basis for
  discovery of the purpose, location, duration, responsible
  agents, and links to related events and resources. The
  resource of type event may not be retrievable if the
  described instantiation has expired or is yet to occur.
  Examples - exhibition, web-cast, conference, workshop,
  open-day, performance, battle, trial, wedding, tea-party,
  conflagration.</dd>

  <dt><em>physical object</em></dt>

  <dd>objects or substances. For example - a person, a
  computer, the great pyramid, a sculpture, wheat. Note that
  digital representations of, or surrogates for, these things
  should use <em>image</em>, <em>text</em> or one of the other
  types.</dd>
</dl>

---

DC.Type vs DC.Format

The IMT scheme which is recommended for the DC element DC.Format uses some terms with the same names as occur in the list of values for DC.Type (eg image and text). However, there is an important distinction between DC.Type - which defines the genre of the item which is primarily related to the meaning or content of the resource, and DC.Format - which indicates details of the particular instantiation, including medium and size. This difference is exemplified in the case of text resources stored in image formats; thus, there is no inconsistency with a resource having DC.Type=textand DC.Format=image/g3fax.

The distinction between electronic and non-electronic is primarily related to instantiation, which is indicated in DC.Format, and not to genre as indicated in DC.Type.

---

Notes

The occurrence of an event may involve the transformation of source resources (such as scripts, scores, artefacts, etc) and may lead to the creation of derived resources (such as a film, tape, transcript, image, pile of ash, etc) but the event has a fundamental identity separate from these other resources. Another function of a record for an event is as an anchor to tie back to related items where there is a large number of them. For example, rather than listing the entire contents of an exhibition in the record for the exhibition, the records for the individual items could point to the exhibition record through Relation=IsPartOf.

The physical object resource type is not intended to cover all non-electronic resources. Many non-electronic resources will primarily match one of the other values: for example, books and certificates are "text", paintings and photographs are "image", an LP record is "sound" and a children's playground is "interactive". To aid resource discovery it may be considered useful to use multiple DC.Type values for a single resource in some cases.

The concept of a Compound or Mixed resource type and the concept of a Collection were both under close scrutiny and discussion, but were rejected as values for DC.Type for Simple Dublin Core™. The reasons for not including these in the list of unqualified allowed for DC.Type metadata was due to retrieval considerations.

For Compound Resources, greater precision for searching for would be achieved by using the more specific DC.Type descriptors - if necessary in multiple usage. For example, a multimedia program with a single URL might have repeated DC.Types:

• DC.Type = sound
• DC.Type = interactive
• DC.Type = text
• DC.Type = image

In general metadata providers should use as many DC.Type elements as necessary to indicate the significant content of the resource.

Collection was considered but rejected because another Resource Type would normally apply as its primary type. Collection can be brought out in a Relation element. It will also be considered as a subelement or subtype of Resource Type for qualified Dublin Core™ (e.g. Text.Collection).

---

Future Work

The taxonomy of "resource types" has been studied in a number of fields, and a number of lexicographies have been presented. These are typically based on specific models of resource types which reflect the needs of the community which developed them. A study of these will be undertaken in order to indicate the crossovers with usages and models from the various communities.

The list here represents a minimalist approach. We expect additional structure for values of DC. Type to emerge from forthcoming discussion, allowing greater granularity of resource types to be expressed within this overall framework. This is likely mainly to involve sub-typing, for example including terms to indicate such things as moving vs. still images, different types of text, etc. However, the structure and syntax of Qualified DC has not been resolved at this time. A refined structure for Type will be implemented according to the general recommendations for Qualified DC.