Summary

  • RFC 2413 carried a 1995 workshop consensus into an Internet-wide publication: fifteen broad terms that librarians, researchers and web publishers could use to describe networked resources.
  • Its flexibility was also a boundary. Optional, repeatable fields and locally chosen values lowered the cost of description, but did not make records interchangeable without community rules.

A shared vocabulary, not a universal catalogue

The Web's discovery problem was already visible in the opening pages of RFC 2413. Indexing services had grown quickly as networked resources multiplied, but the authors argued that indexing was a poor substitute for richer resource description. The response began with a workshop in Dublin, Ohio, in March 1995, where librarians, digital-library researchers and text-markup specialists tried to agree on a compact descriptive core. By September 1998, the result appeared as RFC 2413, an Informational memo—not an Internet Standard. The RFC says so explicitly (RFC 2413, §§1–3).

The list was meant to be broad enough to cross disciplines: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage and Rights. A book, dataset, image or web page could all be described through the same names, even when their detailed records differed. The point was not that fifteen labels captured every domain. It was that different communities might recognize enough shared meaning to exchange a first description.

The trade-off was written into the specification

RFC 2413's goals included simple creation and maintenance, commonly understood semantics, conformance, international scope, extensibility and interoperability among collections and indexing systems. The authors noted that these goals pulled against one another. A vocabulary strict enough to make every record uniform would be harder to apply across very different collections; a vocabulary loose enough for local needs would leave room for records that only looked alike.

The document chose flexibility. Every element was optional and repeatable; elements could appear in any order. A provider might attach significance to the order of repeated values, but a receiving system was not guaranteed to preserve it. The RFC also anticipated controlled vocabularies, while expecting communities to develop local ones. For qualifiers, its compromise was layered: simple discovery tools should be able to ignore them, while richer tools could use them for more precise retrieval (RFC 2413, §3).

That made Dublin Core easier to adopt, but it did not settle what counted as a complete record, which vocabulary a Subject value came from, how a Date was encoded, or whether a local qualifier survived export. “Creator” could be a person, institution or service; a receiving collection still needed a policy for mapping its own records into that broad category. The common label was a meeting point, not a full data contract.

Profiles supplied the missing agreement

The later history made that boundary explicit. RFC 5013, which obsoletes RFC 2413, describes its text as Dublin Core Version 1.1 and places the elements within a wider set of vocabularies and specifications. It says implementation details are typically constrained by application profiles; it also records revisions to the definitions of Contributor and Date, a clarification of Relation and a recommendation for lowercase element names (RFC 5013). Those are later developments, not rules to read backward into the 1998 memo.

Today, DCMI describes its maintained terms as the fifteen familiar properties plus additional properties, classes and encoding schemes. Its application-profile guidance explains how a particular application selects terms and records constraints for its own use (DCMI Metadata Terms; Application Profile Guidelines). The trajectory is instructive: a shared vocabulary made cross-domain conversation possible; profiles and local policies had to make that conversation operational.

The durable lesson

RFC 2413 did not promise that adding metadata would guarantee visibility in a search index, nor that every collection would interpret values identically. It documented an attempt to balance reach with ease of use. The fifteen fields could travel because they were broad. Their meaning became dependable only where a community documented its choices, encoding and preservation rules.

Sources: RFC 2413; RFC 5013; DCMI Metadata Terms; DCMI Application Profile Guidelines.