RFC 2413

Dublin Core Metadata for Resource Discovery

📅 published September 1998, from ietf

RFC 2413: Dublin Core Metadata for Resource Discovery 💖

okay bestie, this one is RFC 2413 🎀 It's titled Dublin Core Metadata for Resource Discovery and it was written by S. Weibel (OCLC Online Computer Library Center, Inc.), J. Kunze (University of California, San Francisco), C. Lagoze (Cornell University), and M. Wolf (Reuters Limited). It's Informational and dated September 1998 📅 The title block doesn't say it obsoletes or updates any other RFCs, so it's standing on its own ✨

1. Status of this Memo 🧚

this memo is for the Internet community to read 📖 it does not define an Internet standard of any kind, and distribution is unlimited 🌈

Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒

2. Abstract 🦋

so the Dublin Core Metadata Workshop Series started in 1995 with an invite-only workshop 🎀 librarians, digital library researchers, content experts, and text-markup experts all got together to push for better discovery standards for electronic resources 🌸 the Dublin Core came out of that as a set of 15 elements of descriptors, built through interdisciplinary and international consensus 🌍 this is the first of a set of Informational RFCs about it 💜 the goal is to introduce the Dublin Core and explain the consensus on what each of the 15 elements means ✨

3. Introduction 🍓

finding stuff on the World Wide Web has gotten so messy because networked resources exploded 💀 web indexing grew fast to meet the demand for discovery tools, and it's useful, but it's kind of a weak stand-in for richer resource descriptions 🙈

a workshop held in March 1995 brought together librarians, digital library researchers, and text-markup specialists to tackle resource discovery for networked resources 🦋 that turned into a whole series of workshops and side activities, now known collectively as the Dublin Core Metadata Workshop Series 🌈

the goals driving the Dublin Core are:

  • Simplicity of creation and maintenance
  • Commonly understood semantics
  • Conformance to existing and emerging standards
  • International scope and applicability
  • Extensibility
  • Interoperability among collections and indexing systems

ngl these goals kind of work against each other sometimes, but they're all things everyone wants 😭 a big chunk of the Workshop Series effort has gone into keeping those tensions as low as possible 💅

one of the main deliverables is a set of elements that the workshop participants agreed are the core elements for cross-disciplinary resource discovery 👑 the term "Dublin Core" refers to this core set of descriptive elements 🎀

early Dublin Core deployments showed that people need to be able to qualify elements for some applications 🔥 so a Dublin Core element can be used without qualification (the way this RFC describes) or with qualifiers that refine its meaning (which future RFCs will cover) ✨ for interoperability's sake, simple indexing and discovery tools should be able to ignore any qualifiers they get, while more advanced, semantically richer tools should be able to use qualifiers for more specialized or precise discovery 🫶

the broad agreements on syntax and semantics from the workshop series will be written up in a series of Informational RFCs, and this document is the first one 🦋

4. Description of Dublin Core Elements 🌸

here's the reference definition of the Dublin Core Metadata Element Set 🔥 you can find more info at [1]:

http://purl.org/metadata/dublin_core

each element below has a descriptive name meant to convey a shared semantic understanding, plus a formal single-word label that makes the syntax easier for encoding schemes 🧚

some environments, like HTML, aren't case-sensitive, but it is recommended best practice to always stick to the case conventions in the element labels below 💖 that way nothing breaks if the metadata gets extracted or converted to a case-sensitive environment like XML (Extensible Markup Language) [2] 🌈

each element is optional and repeatable 🎀 metadata elements can show up in any order 🦋 the order of multiple occurrences of the same element (like Creator) may mean something the provider intended, but ordering isn't guaranteed to survive in every system 💅

to promote global interoperability, a bunch of the element descriptions suggest a controlled vocabulary for their values 🌍 it's assumed that other controlled vocabularies will be developed for interoperability within certain local domains ✨

the metadata elements fall into three groups that roughly show the class or scope of information stored in them: (1) elements mainly about the Content of the resource, (2) elements mainly about the resource viewed as Intellectual Property, and (3) elements mainly about the Instantiation of the resource 👑

     Content          Intellectual Property       Instantiation
     -----------      ---------------------       -------------
     Title                 Creator                  Date
     Subject               Publisher                Format
     Description           Contributor              Identifier
     Type                  Rights                   Language
     Source
     Relation
     Coverage

4.1. Title 🎀

Label: "Title"

the name given to the resource, usually by the Creator or Publisher 📖

4.2. Author or Creator 🦋

Label: "Creator"

the person or organization mainly responsible for creating the intellectual content of the resource 🖋️ like authors of written documents, or artists, photographers, or illustrators for visual resources 🎨

4.3. Subject and Keywords 🌸

Label: "Subject"

the topic of the resource 🔍 subject is usually expressed as keywords or phrases that describe its subject or content 🍓 using controlled vocabularies and formal classification schemes is encouraged 💜

4.4. Description 🧚

Label: "Description"

a textual description of the resource's content, including abstracts for document-like objects or content descriptions for visual resources 🌈

4.5. Publisher 💅

Label: "Publisher"

the entity responsible for making the resource available in its present form, like a publishing house, a university department, or a corporate entity 🏢

4.6. Other Contributor 🫶

Label: "Contributor"

a person or organization that is not named in a Creator element but has made significant intellectual contributions to the resource ✨ their contribution is secondary to anyone named in a Creator element (for example, an editor, transcriber, or illustrator) 🙈

4.7. Date 📅

Label: "Date"

a date tied to the creation or availability of the resource 🗓️ recommended best practice is defined in a profile of ISO 8601 [3] that includes (among others) dates of the forms YYYY and YYYY-MM-DD 💖 in this scheme, for example, the date 1994-11-05 means November 5, 1994 🎂

4.8. Resource Type 🔥

Label: "Type"

the category of the resource, like home page, novel, poem, working paper, technical report, essay, or dictionary 📚 for interoperability's sake, Type should be selected from an enumerated list that the workshop series is still developing 🛠️

4.9. Format 🦋

Label: "Format"

the data format and, optionally, dimensions (like size or duration) of the resource 📐 format is used to identify the software and possibly hardware needed to display or operate the resource 💻 for interoperability, the format should be selected from an enumerated list that the workshop series is still developing 🌸

4.10. Resource Identifier 🔑

Label: "Identifier"

a string or number used to uniquely identify the resource 🆔 examples for networked resources include URLs and URNs (when implemented) 🌐 other globally-unique identifiers, like International Standard Book Numbers (ISBN) or other formal names, are also candidates for this element 📖

4.11. Source 🧚

Label: "Source"

information about a second resource that the present resource is derived from 🍃 it's generally recommended that elements only contain information about the present resource, but this element may hold metadata for the second resource when that's important for discovering the present resource 💜

4.12. Language 🌍

Label: "Language"

the language of the intellectual content of the resource 🗣️ recommended best practice is defined in RFC 1766 [4] 💅

4.13. Relation 🫶

Label: "Relation"

an identifier of a second resource and its relationship to the present resource 🔗 this element is for expressing linkages among related resources ✨ for interoperability, relationships should be selected from an enumerated list that the workshop series is still developing 🎀

4.14. Coverage 🌈

Label: "Coverage"

the spatial or temporal characteristics of the intellectual content of the resource 🌌 spatial coverage refers to a physical region (like a celestial sector) using place names or coordinates (like longitude and latitude) 📍 temporal coverage refers to what the resource is about, not when it was created or made available (that one belongs in the Date element) ⏳ temporal coverage is typically specified with named time periods (like neolithic) or the same date/time format [3] recommended for the Date element 🏛️

4.15. Rights Management 🔐

Label: "Rights"

a rights management statement, an identifier that links to a rights management statement, or an identifier that links to a service providing information about rights management for the resource 📜

5. Security Considerations 🚨

okay this part is actually super chill 😌 the Dublin Core element set poses no risk to computers and networks 💻 it does pose minimal risk to searchers who get incorrect or private information because of careless mapping from rich data descriptions to the simple Dublin Core scheme ⚠️ no other security concerns are likely to come up from the element description consensus documented here 🛡️

6. References 📚

[1] Further information about the Dublin Core Metadata Element Set, http://purl.org/metadata/dublin_core

[2] Extensible Markup Language (XML), http://www.w3.org/TR/REC-xml

[3] Date and Time Formats (based on ISO 8601), W3C Technical Note, http://www.w3.org/TR/NOTE-datetime

[4] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.

7. Authors' Addresses 🎀

Okay bestie, here are the four legends who wrote this thing. Their contact details are copied exactly below so you can reach out. Stuart's first, obviously 💅

Stuart L. Weibel
OCLC Online Computer Library Center, Inc.
Office of Research
6565 Frantz Rd.
Dublin, Ohio, 43017, USA

Phone: +1 614-764-6081
Fax:   +1 614-764-2344
EMail: weibel@oclc.org
John A. Kunze
Center for Knowledge Management
University of California, San Francisco
530 Parnassus Ave, Box 0840
San Francisco, CA  94143-0840, USA

Phone: +1 510-525-8575
Fax:   +1 415-476-4653
EMail: jak@ckm.ucsf.edu
Carl Lagoze
University Library and Department of Computer Science
Cornell University
Ithaca, NY  14853, USA

Phone: +1 607-255-6046
Fax:   +1 607-255-4428
EMail: lagoze@cs.cornell.edu
Misha Wolf
Reuters Limited
85 Fleet Street
London EC4P 4AJ, UK

Phone: +44 171-542-6722
Fax:   +44 171-542-8314
EMail: misha.wolf@reuters.com

Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈

So here's the deal with copying this doc 🫶 You're allowed to copy it and hand it to people, and you can make derivative works that comment on or explain it or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph stay on every copy and derivative work.

BUT the document itself may not be modified in any way. So no removing the copyright notice, and no removing the references to the Internet Society or other Internet organizations. There are two exceptions. First, you can change it when you're developing Internet standards, but then you have to follow the copyright procedures in the Internet Standards process. Second, you can change it when you need to translate it into languages other than English. 🌸

These permissions are perpetual, which means the Internet Society and its successors or assigns can never take them back. 💜

Now the legal part, which I'm putting in caps because it's serious 😭 This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🧚

📦 where this page comes from