summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5013.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5013.txt')
-rw-r--r--doc/rfc/rfc5013.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5013.txt b/doc/rfc/rfc5013.txt
new file mode 100644
index 0000000..3f92df9
--- /dev/null
+++ b/doc/rfc/rfc5013.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group J. Kunze
+Request for Comments: 5013 University of California
+Obsoletes: 2413 T. Baker
+Category: Informational Dublin Core Metadata Initiative
+ August 2007
+
+
+ The Dublin Core Metadata Element Set
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Abstract
+
+ This document defines fifteen metadata elements for resource
+ description in a cross-disciplinary information environment.
+
+1. Introduction
+
+ The Dublin Core Metadata Workshop Series began in 1995 with an
+ invitational workshop that brought together librarians, digital
+ library researchers, content experts, and text-markup experts to
+ promote better discovery standards for electronic resources. The
+ resulting metadata element set defines fifteen metadata elements for
+ resource description in a cross-disciplinary information environment.
+
+ This document contains the current text of Dublin Core "Version 1.1".
+ Version 1.1 is the basis of ANSI/NISO Z39.85-2001 [Z39.85]. The text
+ in the present RFC closely follows the text in the 2007 revision of
+ ANSI/NISO Z39.85, especially Sections 2-6 and 10-12 [Z39.85-2007].
+ The present RFC obsoletes RFC 2413 [RFC2413], which was the first
+ published version of the Dublin Core ("Version 1.0"). The main
+ differences between the present RFC and RFC 2413 are in the wording
+ of definitions -- for Contributor and Date (semantically broadened),
+ for Relation (clarified), and in the general removing of redundant
+ references to "the content of" a resource. In addition, the present
+ RFC recommends lowercase element names (consistent with RDF property
+ types), remains silent about the unrestrictedness of element ordering
+ and repeatability (application profiles being the proper place to
+ discuss such topics), and references the current abstract model,
+ vocabularies, and namespace policies in which the Dublin Core is
+ embedded.
+
+
+
+
+
+
+Kunze & Baker Informational [Page 1]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+2. Foreword
+
+ The Dublin Core Metadata Element Set is a vocabulary of fifteen
+ properties for use in resource description. The name "Dublin" is due
+ to its origin at a 1995 invitational workshop in Dublin, Ohio; "core"
+ because its elements are broad and generic, usable for describing a
+ wide range of resources.
+
+ The fifteen element "Dublin Core" described in this document is part
+ of a larger set of metadata vocabularies and technical specifications
+ maintained by the Dublin Core Metadata Initiative (DCMI). The full
+ set of vocabularies, DCMI Metadata Terms [DCTERMS], also includes a
+ set of resource classes, the DCMI Type Vocabulary [DCTYPE]. The
+ terms in DCMI vocabularies are intended to be used in combination
+ with terms from other compatible vocabularies in the context of
+ application profiles and on the basis of the DCMI Abstract Model
+ [DCAM].
+
+ All changes made to terms of the Dublin Core Metadata Element Set
+ since 2001 have been reviewed by a DCMI Usage Board in the context of
+ a DCMI Namespace Policy [DCNMSPC]. The namespace policy describes
+ how DCMI terms are assigned Uniform Resource Identifiers (URIs) and
+ sets limits on the range of editorial changes that may allowably be
+ made to the labels, definitions, and usage comments associated with
+ existing DCMI terms.
+
+3. Scope and Purpose
+
+ The Dublin Core Metadata Element Set is a standard for cross-domain
+ resource description. As in RFC 3986 [RFC3986], "Uniform Resource
+ Identifier (URI): Generic Syntax", this specification does not limit
+ the scope of what might be a resource.
+
+ The elements described in this document are typically used in the
+ context of an application profile which constrains or specifies their
+ use in accordance with local or community-based requirements and
+ policies. The specification of such implementation detail is outside
+ the scope of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kunze & Baker Informational [Page 2]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+4. Definitions
+
+ DCMI -- the Dublin Core Metadata Initiative, maintenance agency for
+ Dublin Core Metadata Element Set.
+
+ Resource -- anything that might be identified (the same definition as
+ in RFC 3986 and in the DCMI Abstract Model).
+
+ Lifecycle of a resource -- a sequence of events that mark the
+ development and use of a resource. Some examples of events in a
+ lifecycle are: conception of an invention, creation of a draft,
+ revision of an article, publication of a book, acquisition by a
+ library, transcription to magnetic disk, migration to optical
+ storage, translation into English, and derivation of a new work
+ (e.g., a movie).
+
+5. The Element Set
+
+ In the element descriptions below, each element has a descriptive
+ label ("label") for human consumption and a unique token ("name") for
+ use in machine processing.
+
+ In accordance with the DCMI Namespace Policy [DCNMSPC], the "name" of
+ an element is appended to a DCMI namespace URI to construct a Uniform
+ Resource Identifier as a globally unique identifier for that element.
+ The use of element names and URIs in the context of different
+ implementation technologies is explained in DCMI Encoding Guidelines
+ [DCENCOD].
+
+6. The Elements
+
+Element Name: title
+
+ Label: Title
+ Definition: A name given to the resource.
+
+Element Name: creator
+
+ Label: Creator
+ Definition: An entity primarily responsible for making the resource.
+ Comment: Examples of a Creator include a person, an organization,
+ or a service. Typically, the name of a Creator should
+ be used to indicate the entity.
+
+
+
+
+
+
+
+
+Kunze & Baker Informational [Page 3]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+Element Name: subject
+
+ Label: Subject
+ Definition: The topic of the resource.
+ Comment: Typically, the subject will be represented using
+ keywords, key phrases, or classification codes.
+ Recommended best practice is to use a controlled
+ vocabulary. To describe the spatial or temporal
+ topic of the resource, use the Coverage element.
+
+Element Name: description
+
+ Label: Description
+ Definition: An account of the resource.
+ Comment: Description may include but is not limited to:
+ an abstract, a table of contents, a graphical
+ representation, or a free-text account of
+ the resource.
+
+Element Name: publisher
+
+ Label: Publisher
+ Definition: An entity responsible for making the resource available.
+ Comment: Examples of a Publisher include a person, an
+ organization, or a service. Typically, the name of
+ a Publisher should be used to indicate the entity.
+
+Element Name: contributor
+
+ Label: Contributor
+ Definition: An entity responsible for making contributions to the
+ resource.
+ Comment: Examples of a Contributor include a person, an
+ organization, or a service. Typically, the name of a
+ Contributor should be used to indicate the entity.
+
+Element Name: date
+
+ Label: Date
+ Definition: A point or period of time associated with an event
+ in the lifecycle of the resource.
+ Comment: Date may be used to express temporal information
+ at any level of granularity. Recommended best
+ practice is to use an encoding scheme, such as
+ the W3CDTF profile of ISO 8601 [W3CDTF].
+
+
+
+
+
+
+Kunze & Baker Informational [Page 4]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+Element Name: type
+
+ Label: Type
+ Definition: The nature or genre of the resource.
+ Comment: Recommended best practice is to use a controlled
+ vocabulary such as the DCMI Type Vocabulary
+ [DCTYPE]. To describe the file format, physical medium,
+ or dimensions of the resource, use the Format element.
+
+Element Name: format
+
+ Label: Format
+ Definition: The file format, physical medium, or dimensions
+ of the resource.
+ Comment: Examples of dimensions include size and duration.
+ Recommended best practice is to use a controlled
+ vocabulary such as the list of Internet Media Types
+ [MIME].
+
+Element Name: identifier
+
+ Label: Identifier
+ Definition: An unambiguous reference to the resource within a given
+ context.
+ Comment: Recommended best practice is to identify the
+ resource by means of a string conforming
+ to a formal identification system.
+
+Element Name: source
+
+ Label: Source
+ Definition: A related resource from which the described resource
+ is derived.
+ Comment: The described resource may be derived from the
+ related resource in whole or in part. Recommended
+ best practice is to identify the related resource
+ by means of a string conforming to a formal
+ identification system.
+
+Element Name: language
+
+ Label: Language
+ Definition: A language of the resource.
+ Comment: Recommended best practice is to use a controlled
+ vocabulary such as RFC 4646 [RFC4646].
+
+
+
+
+
+
+Kunze & Baker Informational [Page 5]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+Element Name: relation
+
+ Label: Relation
+ Definition: A related resource.
+ Comment: Recommended best practice is to identify the
+ related resource by means of a string conforming
+ to a formal identification system.
+
+Element Name: coverage
+
+ Label: Coverage
+ Definition: The spatial or temporal topic of the resource, the
+ spatial applicability of the resource, or the
+ jurisdiction under which the resource is relevant.
+ Comment: Spatial topic and spatial applicability may be a named
+ place or a location specified by its geographic
+ coordinates. Temporal topic may be a named period,
+ date, or date range. A jurisdiction may be a named
+ administrative entity or a geographic place to which the
+ resource applies. Recommended best practice is to use a
+ controlled vocabulary such as the Thesaurus of
+ Geographic Names [TGN]. Where appropriate, named places
+ or time periods can be used in preference to numeric
+ identifiers such as sets of coordinates or date ranges.
+
+Element Name: rights
+
+ Label: Rights
+ Definition: Information about rights held in and over the resource.
+ Comment: Typically, rights information includes a statement about
+ various property rights associated with the resource,
+ including intellectual property rights.
+
+7. Security Considerations
+
+ The Dublin Core element set poses no risk to computers and networks.
+ It poses minimal risk to searchers who obtain incorrect or private
+ information due to careless mapping from rich data descriptions to
+ the Dublin Core elements. No other security concerns are likely.
+
+10. Informative References
+
+ [DCAM] DCMI Abstract Model.
+ http://dublincore.org/documents/abstract-model/
+
+ [DCENCOD] DCMI Encoding Guidelines.
+ http://dublincore.org/resources/expressions/
+
+
+
+
+Kunze & Baker Informational [Page 6]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+ [DCNMSPC] DCMI Namespace Policy.
+ http://dublincore.org/documents/dcmi-namespace/
+
+ [DCTERMS] DCMI Metadata Terms.
+ http://dublincore.org/documents/dcmi-terms/
+
+ [DCTYPE] DCMI Type Vocabulary.
+ http://dublincore.org/documents/dcmi-type-vocabulary/
+
+ [ISO3166] ISO 3166 - Codes for the representation of names of
+ countries. http://www.din.de/
+
+ [MIME] Internet Media Types.
+ http://www.iana.org/assignments/media-types/
+
+ [RDF] Resource Description Framework. http://www.w3.org/RDF/
+
+ [RFC2413] Weibel, S., Kunze, J., Lagoze, C., and M. Wolf, "Dublin
+ Core Metadata for Resource Discovery", RFC 2413,
+ September 1998.
+
+ [RFC2731] Kunze, J., "Encoding Dublin Core Metadata in HTML", RFC
+ 2731, December 1999.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
+ Languages", BCP 47, RFC 4646, September 2006.
+
+ [TGN] Getty Thesaurus of Geographic Names.
+ http://www.getty.edu/research/tools/vocabulary/
+ tgn/index.html
+
+ [W3CDTF] Date and Time Formats, W3C Note.
+ http://www.w3.org/TR/NOTE-datetime
+
+ [Z39.85] ANSI/NISO Standard Z39.85-2001 - The Dublin Core
+ Metadata Element Set.
+ http://www.niso.org/standards/resources/Z39-85.pdf
+
+ [Z39.85-2007] ANSI/NISO Standard Z39.85-2007 - The Dublin Core
+ Metadata Element Set.
+ http://www.niso.org/standards/resources/Z39-85-2007.pdf
+
+
+
+
+
+
+Kunze & Baker Informational [Page 7]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+Appendix A: Further Reading
+
+ (This appendix is not part of the Z39.85 standard. It is included
+ for information only.)
+
+ Further information about the Dublin Core metadata element set is
+ available at the URL,
+
+ http://dublincore.org/
+
+ This Web site contains information about workshops, reports, working
+ group papers, projects, and new developments concerning the Dublin
+ Core Metadata Initiative (DCMI).
+
+Appendix B: Maintenance Agency
+
+ (This appendix is not part of the Z39.85 standard. It is included
+ for information only.)
+
+ The Dublin Core Metadata Initiative (DCMI) is responsible for the
+ development, standardization, and promotion of the Dublin Core
+ metadata element set. Information on DCMI is available at the URL,
+
+ http://dublincore.org/
+
+Authors' Addresses
+
+ John A. Kunze
+ California Digital Library
+ University of California, Office of the President
+ 415 20th St, 4th Floor
+ Oakland, CA 94612-3550, USA
+
+ Fax: +1 510-893-5212
+ EMail: jak@ucop.edu
+
+ Thomas Baker
+ Director, Specifications and Documentation
+ Dublin Core Metadata Initiative
+ c/o OCLC Research
+ Dublin, OH 43017, USA
+
+ EMail: tbaker@tbaker.de
+
+
+
+
+
+
+
+
+Kunze & Baker Informational [Page 8]
+
+RFC 5013 Dublin Core Metadata August 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Kunze & Baker Informational [Page 9]
+