"Why would you do this to yourself, [Mike Nason]?" - Everyone, to me.
If I've shared this 5000+ 7000+ word document with you, it's either because I'm taking a look at your DSpace schema or because I believe you to share the same affliction of intense and unhealthy relationships with metadata that I have (or, it's because I apparently have no respect for your time). At UNB, we are in the middle of a migration from Islandora to DSpace. Islandora uses MODS, which is basically like if MARC21 were XML, its schema is both more complex and more rigid in its application/interpretation. Dublin Core, on the other hand, is a lot looser. Sometimes this looseness is in the application of element "qualifiers" (these are usually "attributes" in XML schema). Sometimes this looseness is in the fabrication of entirely new elements that aren't part of Dublin Core proper.
Because I have an opportunity to get things right the first third time (hahahahahahahahaha.gif), I want to make sure we move our existing metadata into these schema in a responsible way that I will not want to murder myself over later. Keeping in Qualified Dublin Core as a starting point, ETD-MS as a potential schema for theses and dissertations, and a custom institutional namespace for metadata related to the university proper, I'm going to compare schema shared with me against notes and my understanding as I go along.
This is, in a number of ways, a learning exercise for me, because I am not fluent in the bending of Dublin Core. MODS does not afford bending (regardless of what you might see in Islandora metadata records). Librarians, on the other hand, bend more than one might think.
Let's get to it.
Let's discuss, first, our schema guidelines:
<aside> 📄 Simple Dublin Core properties are those original 15 elements first defined by the Dublin Core Metadata Workshop Series in the mid-1990s. Though this categorization is conceptually useful, Simple Dublin Core is a somewhat deprecated notion now subsumed into the dc/terms/namespace as high-level properties.
Qualified Dublin Core properties are refinements of the original 15 elements (with some elemental additions defined more recently by the DCMI), which are presently managed in the dc/terms/namespace.
Custom Dublin Core properties are custom refinements of the controlled dc/terms/elements made by local schema developers. While the Dublin Core standard does not allow for custom elements to be asserted, it does allow for the custom refinement of existing elements through the Dumb-Down Principle. This principle states that local refinements on the Dublin Core elements are supported as long as external applications can “ignore any qualifier and use the description as if it were unqualified” [7]. Adherence to this principle ensures that all enterprise-specific metadata elements can be dumbed down and ingested by external systems, even with some loss of specificity, since all custom elements are sub-properties of controlled Dublin Core elements.
From https://doi.org/10.1002/bul2.2017.1720430211
</aside>
The takeaway here is that: "local refinements on the Dublin Core elements are supported as long as external applications can 'ignore any qualifier and use the description as if it were unqualified.'" Additionally, from Dublin Core (all emphasis mine):
<aside> 📄 A refined element shares the meaning of the unqualified element, but with a more restricted scope. A client that does not understand a specific element refinement term should be able to ignore the qualifier and treat the metadata value as if it were an unqualified (broader) element. The definitions of element refinement terms for qualifiers must be publicly available. -
Encoding Scheme
These qualifiers identify schemes that aid in the interpretation of an element value. These schemes include controlled vocabularies and formal notations or parsing rules. A value expressed using an encoding scheme will thus be a token selected from a controlled vocabulary (e.g., a term from a classification system or set of subject headings) or a string formatted in accordance with a formal notation (e.g., "2000-01-01" as the standard expression of a date). If an encoding scheme is not understood by a client or agent, the value may still be useful to a human reader. The definitive description of an encoding scheme for qualifiers must be clearly identified and available for public use.
All of the qualifiers listed in this document fall into one of these two categories. Specific guidance is given below for element refinements. If a particular encoding scheme is available for the element and or/element refinement, its application is generally described either in this document or in the documentation available with the encoding scheme itself. Audience, Provenance, and Rights Holder, which are at the element-level but not one of the original 15 elements, are described along with the other elements. Additional qualifier categories may evolve over time and with implementation experience. The qualifiers listed here do not constitute a closed set, designed to meet all of the descriptive needs of implementors. Rather, they form the foundation for a larger body of qualifiers that will evolve as additional qualifiers are developed by various communities, some of which may eventually be submitted to the DCMI Usage Board for review and approval. Implementors may deploy the qualifiers on these lists with confidence that they conform to the Dumb-Down Principle, and are encouraged to use these qualifiers as examples to guide the development of local qualifiers for Dublin Core™ metadata elements.
</aside>
TAKEAWAYS INCLUDE
So here's the good news.
namespace.element.qualifier.qualifier part of your metadata should still be as useful if you only have access to namespace.element.dcterms should be used a lot more than it already is, but I think everyone just assumes that for those original 15 elements, it's fine to keep using them. And, I guess, it is? But this would explain the mixing and matching. I'm not sure it's better to just slap qualifiers up when there's a whole schema that includes those elements. Fascinating!thesis.|dc.)Specifically specific.
ETD-MS is a simple schema specific to theses (though, for our purposes, I'd consider it reasonable to apply it to anything in the "degree requirement" oeuvre). It leverages very bare-bones Dublin Core and adds in some elements that are specific to theses and dissertations. The schema is as follows: