I should have done this a long time ago. But, better late than never, as they say.
In the past, I interned at an archives to develop a digital archival collections management system. Having chosen to study rare books and manuscripts instead of archives during Library School, I spent a lot of time researching standards and procedures for archival collections management and development.
When I finally got down to the development phase, I knew enough to choose namespaces/elements for the metadata (to create fields which would be filled out when the metadata was added to cataloged objects). I knew the open source software I was customizing used Dublin Core, and I knew the basic requirements.
What still troubles me, is putting it all together. Which is where this post comes in. I have begun (again) to read about Dublin Core, and my goal for this post is to order the context and basics in my head, so I can move on from there to more fully understanding how Dublin Core affects and is used in metadata creation.
Dublin Core was established as a standard for “core metadata” that describes electronic resources simply and generically. The core comprises fifteen metadata elements:
I remember some of these from my archival internship, when I set up Dublin Core namespaces in CollectiveAccess.
The Dublin Core Metadata Initiative (DCMI) is now incorporated as a non-profit organization hosted at the National Library Board of Singapore.
Dublin Core terms
Dublin Core Metadata vocabularies distinguish four types of terms
- Properties – or “Elements,” and also called “metadata fields,” are the fifteen core attributes listed above (e.g., creator, title, publisher).
- Classes – are groups of resources that have properties in common and are grouped together under one concept. Examples include “Agent” and “BibliographicResource.” They can be categories, or types of things, such as “books” or “people.” Classes and Properties are related either by a has domain relationship or a has range relationship. A domain relationship means that the property describes the class. A range relationship indicates that the class is a value of the property.
This was much harder for me to wrap my head around than Linked Data. But. If I understand correctly, using the examples of physical books in a collection (bear with me as I transcribe my thought processes):
The class: BibliographicResource describes books, articles, or other documentary resources.
Reverse-engineering the description in the User Guide (see references below) for the has domain relationship: “… where the domain indicates the class of resources that the property should be used to describe,” I worked with: “the property X describes the class of resources Y.” For the has range relationship (“… the range indicates the class of resources that should be used as values for that property,” I worked with: “Class Y is a value of the property X.”
Using the DCMI Metadata Terms information on Classes (see references below), I plugged in the class “BibliographicResource” for Y, and the property “Format” for X.
Following through, my two equations (am I doing MATH?!) become: has domain: “The property ‘Format’ describes the class of resources “BibliographicResource.” Well, that doesn’t look right… Bibliographic resource is a type of format, not the other way around. Has range: “The class ‘BibliographicResource’ is a value of the property ‘Format’. Now, knowing what I do about metadata, I can definitely see entering the value “BibliographicResource” into a field called “Format.” Therefore, I believe that the property “Format” is related to the class “BibliographicResource” by a has range relationship.
I think this is possibly oversimplified, but am I right, so far? Or wrong?
- Datatypes – also called Syntax Encoding Schems (SES), these are the rules that specify how a value must be structured. For example, the DCMI Metadata Term W3CDTF determines that a date must be written as: YYYY-MM-DD, according to ISO 8601.
- Vocabulary encoding schemes (VES) – or Concept Scheme, identifies controlled vocabularies whose terms may be used as values. Properties may be constrained by a VES, so that the controlled vocabulary/ies dictate/s what values may be used with that property.
How Linked Data fits in
Linked Data, a method of exposing, sharing, and connecting data on the Semantic Web using Uniform Resource Identifiers (URIs) and Resource Description Framework (RDF), uses DCMI terms as one of its key vocabularies.
Linked data graphs look a bit like the brainstorming webs I still use, with “subjects,” “predicates,” and “objects” linked together in relationships. So, a graph that describes a version of a book is linked to its properties, e.g., title, author, etc. Once I understood the example, it was actually pretty intuitive to read these graphs.
Connecting what I’ve learned with what I’ve done
Thanks for making it all the way through my post! It felt pretty dense to me. All that’s left is a bit of personal reflection:
I was familiar with the 15 original properties from my work as an archival intern. Much of what I did then was make sure that these were present as the building blocks for the namespaces in the CollectiveAccess database. My recent indexing work which relies on enterprise business vocabularies made it very easy for me to understand the relationship between properties and Vocabulary Encoding Schemes. The rest of this was new to me, as evidenced by my struggles to understand. I have a long way to go, but it does feel like I’m in a pretty good starting position.
User Guide – DCMI_MediaWiki [Stephanie Ruhle, Tom Baker, Pete Johnston. 6 September 2011 (Accessed 4/8/2014)]
Most of the information above comes from this document. Where I have been unable to paraphrase, I used quotations to indicate directly quoted text.
Domains and Ranges for DCMI Properties [Andy Powell, Pete Johnston, Thomas Baker. January 14, 2008: Copyright © 1995-2014 DCMI; Licensed under a Creative Commons Attribution 3.0 Unported License (Accessed 4/10/2014)]
This resource was unhelpful in my current state of knowledge – it described the relationships even more technically.
Much more helpful, this provided me with the clues for my breakthrough moment in deciphering relationships between classes and properties.
Date and Time Formats [Misha Wolf and Charles Wicksteed. Document status: August 27, 1998 (Accessed 4/10/2014)]
Describes the date and time formats specified in ISO 8601.