1:1 Reconsidered - Dublin Core® Metadata Initiative

1:1 Reconsidered
DC-6, November 4, 1998
July 97: RLG Metadata Summit
Archives, museums, libraries
Identified need for flexible description of
resource manifestations
Metadata Summit: Meeting Report. Willy
Cromwell-Kessler and Ricky Erway. July, 1997.
DC-5, Helsinki, October 97
RLG proposal raised
1:1 principle emerges
1:1 Status
Published in D-Lib Magazine
“The [DC-5] discussion resulted in consensus
concerning what came to be known as the 1:1
principle -- each resource should have a discrete
metadata description, and each metadata description
should include elements relating to a single resource.
It is desirable to be able to link these
descriptions in a coherent and consistent
manner [emphasis added].”
DC-5: The Helsinki Metadata Workshop: A Report on
the Workshop and Subsequent Developments
1:1 Status
Crept into DC vocabulary
Not represented in RFC
Lacks operational definition and
application guidelines
Adoption by implementers uncertain
Our Best Understanding
of 1:1
Any given set of metadata refers to a
single discrete resource
Implications of 1:1
Precise granularity
Proliferation of metadata records
Large retrieval sets
Increased record maintenance
Access vocabulary split over multiple
Confusion applying selected elements,
e.g., Creator, Publisher
One record for resource with compound
Digital image from photograph
Metadata conveys aspects of original resource
(e.g., photographer), and
Metadata conveys aspects of digital manifestation
(e.g., Format)
One record for multiple formats
Electronic text manifest in ASCII, Word, PDF
Metadata conveys aspects of each manifestation
One record for set of resources
Collection of images
Metadata conveys aspects of collection and each
discrete resource
RDF Model
<rdf:Description about = “URI”>
Appears to accommodate examples
If 1:1 (as we understand it) does not
enable implementers to accomplish the
requirements expressed above, specific
expressed user needs are not addressed
If 1:1 does enable implementers to
accomplish the requirements expressed
above, then the concept appears to
accommodate user needs
Action Items
Revisit “1:1”
Determine usefulness and necessity as a
DC precept
Ensure that user needs are determined
and addressed
Formally adopt, allow, or reject
Action Items
If “adopt,” then:
Define and ratify in RFC
Develop application guidelines
Monitor implementation experiences and
user satisfaction

similar documents