Dublin "Core" - fifteen elements forever?

[tombaker]

The name recognition of "Dublin Core" is a blessing and a curse. It is a blessing because the message is easy to grok. "The Dublin Core" is the starting point for countless "Intro to Metadata" courses. But it is a curse because it enshrines, and continues to promote, a selection of terms that we all recognize to be outdated and flawed.

Consider Coverage, its "lumpy" range reflected in the outrageous LocationPeriodOrJurisdiction class, or that some of us routinely recommend subproperties of Date over Date itself.

In the 1990s, DCMI was a pioneer in using "core" to distinguish the generic and useful from the domain-specific, less frequently required. One need only consider the numerous other "cores" in the metadata world to see that this is and remains a valuable model.

Today, however, the "fifteen elements" we are stuck with prevent us from using "core" and "non-core" to make a more dynamic and flexible distinction between terms that we now see, today, with wisdom of hindsight and with twenty years of implementation experience, as generic and important from terms that we might prefer to de-emphasize or even mark as archaic.

As recently as ten years ago, I suspect, any proposal to change "the core" would have been controversial.

Is this still the case? Might people, today, welcome a Dublin Core freed of some cruft, modernized, evolving with the times, a few historical errors corrected, with documentation restructured around the terms we really do want to promote? Updating the "core" could also provide a way to keep our message focused as domain-specific terms are added in support of DCMI-endorsed application profiles. And do we still want to give equal billing to all of those vocabulary encoding schemes?

One great place to start could be to end the perennially confusing distinction between the /terms/ and /elements/1.1/ namespaces. Might we simply declare them to be equivalent and recommend that people use /terms/? The dwindling number of us who recall those long discussions at DC-2005/Madrid now struggle to explain the point to new generations, and indeed our own documentation has already softened that distinction. Putting this issue definitively to rest seems like a prerequisite for redefining Dublin Core as something other than the DC-15 of 1998.

I pause here for your replies.

[kcoyle]

@tombaker I'm not exactly sure what you are proposing, but I feel strongly that the original core of 15 had many advantages over the extended version of Terms. It's true that it might be best to update definitions, etc. of the original 15 in 1.1, but the DCTerms today contains an odd "tail" of terms that seem out of place with the true core. I'm thinking of terms like: the "accruals", the various "referencedBy/references", "educational level", and some of the ones specific to academic publications. Many of these are handled in other available vocabularies (e.g. PROV, CiTO, schema) today and may not be needed the the DC core vocabulary space, especially if they are not heavily used in open metadata.

The list of vocabulary encoding schemes is so entirely out of date to be pretty much useless. It may have only historical value. Unfortunately the VES is made up of some things that are lists and some that are what are essentially
"methods" such as those that identify the provenance of a composed value, such as for LCSH and the Decimal Classification. Fortunately, LoC has created identifiers for the classification schemes themselves apart from the classification numbers (not all of which have been converted to RDF-like lists). Perhaps a "transition period" could include indications in the VES area of the RDF identifier that should be used, and any sources of identifiers for individual elements of those lists.

What we don't know is where some of these "non-15" items have been used nor how frequently. I haven't seen any statistics coming out on term use since that time ages ago. (blogged here and here) Another difficulty is that based on the Linked Open Vocabularies, the 1.1 is one of the most used vocabularies in the LOV space in terms of being used with other vocabularies. I don't know if that is due to inferencing on the DCTerms subclasses so we would have to find someone there who can answer that.

[tombaker]

@kcoyle

@tombaker I'm not exactly sure what you are proposing, but I feel strongly that the original core of 15 had many advantages over the extended version of Terms.

To avoid confusion, some terminology:

When I refer to "DCMI Metadata Terms", I mean everything in the "DCMI Metadata Terms" document:

• the properties and classes of the /terms/ namespace
• the properties of the /elements/1.1/ namespace
• the DCMI Type Vocabulary
• Vocabulary Encoding Schemes
• Datatypes (Syntax Encoding Schemes), and
• a small namespace for VocabularyEncodingScheme, memberOf, domainIncludes, and rangeIncludes.

When I refer to "the Dublin Core" I mean the fifteen elements, or "DC-15", whether in their /term/ and /elements/1.1/ variants.

We currently have no way to mark terms as "archaic" or "deprecated".

We currently have no way to designate any property as a "core property" because we are still in effect bound by the decisions made for DC-15 in 1998.

It's true that it might be best to update definitions, etc. of the original 15 in 1.1, but the DCTerms today contains an odd "tail" of terms that seem out of place with the true core. I'm thinking of terms like: the "accruals"...

I completely agree, though that is not what I am suggesting. Rather I'm thinking, to take the most obvious example, that if we are already steering people away from DC contributor coverage and towards the more specific subproperties Temporal Coverage and Spatial Coverage (see my comment in the Schema.org mapping issue), we should consider taking DC contributor out of "the core" and replacing it with Temporal Coverage and Spatial Coverage.

Taking this one simple step would already leave us with a core of sixteen properties. I do not think "the core" should necessarily be much larger than that - it certainly would not include the "accrual" properties, for example. It might just be slightly different, updated to reflect what we currently understand to be best practice, and hopefully improved. My point is that it currently feels like we are being held back by history - the /elements/1.1/ namespace and a selection of "core" terms from 1998 - from making any changes to the core that could improve it as a "core" set of properties.

The list of vocabulary encoding schemes is so entirely out of date to be pretty much useless.

I think of them as something like SKOS concept schemes without SKOS concepts and concept URIs - just a (possibly unenumerated) set of labels that are designated as being, in some sense, "inScheme" with respect to the vocabulary encoding scheme URI. At any rate, I agree that they are mostly just of historical interest. That is indeed part of my point. Should they continue to be documented in a single "DCMI Metadata Terms" document, or could we find a way to mark the entire category as "archaic" or "deprecated", perhaps with a historical note, and move them off to the side?

What we don't know is where some of these "non-15" items have been used nor how frequently.

I certainly agree that adjustments to the core should, where possible, be justified by usage statistics. But we already recommend, for example, using Temporal Coverage and Spatial Coverage over using just Coverage, and Coverage remains part of "the core". Hence my point: that we re-consider whether we need to be bound by decisions from 1998 about which properties in our namespaces really should be considered as "core".

[kcoyle]

I see a number of issues. First is that there is no "model" for DC Terms - no description or diagram of entities and relationships. While many RDF vocabularies have a reference page similar to the DC Terms page with classes and properties in alphabetical order, that does not constitute a description of the model. For DC 1.1 in a sense there was no model, or at least it was a very very simple model - 1 resource and 15 data elements in a flat list. DC Terms is more complex so a description of the model is needed. (I note that pulling DCMT into Protege gives a visual of the vocabulary that is at least a bit better than the alphabetical list, because it shows super- and sub- relationships.)

Then there is the issue of classes: DC 1.1 had no classes. DC Terms has a number of classes whose utility is not clear to me. Some seem to be better suited as properties (e.g. Location and RightsStatement; AccrualMethod vs methodOfAccrual). Assuming that these classes are useful, there needs to be some demonstration ("cookbook"?) of how they MAY be used.

I'm not terribly bothered by dct:coverage with dct:temporal and dct:spatial as subclasses. I see no need to remove dct:coverage, and those who wish can describe time or space as they wish. dct:coverage might be used in areas where a more granular element is not available. I AM bothered by this:

because I do not recognize extent to be a subclass of format. (I'm not sure at the moment about medium.) All of these questions may have once been answered, but I doubt if those answers are available to the world. Explaining DCMT well may be the best place to start. It would be difficult to make any revisions unless we fully understand the current model.

[tombaker]

@kcoyle

Then there is the issue of classes: DC 1.1 had no classes. DC Terms has a number of classes whose utility is not clear to me. Some seem to be better suited as properties (e.g. Location and RightsStatement; AccrualMethod vs methodOfAccrual). Assuming that these classes are useful, there needs to be some demonstration ("cookbook"?) of how they MAY be used.

Most (or all?) of the classes were introduced in the context of assigning domains and ranges to properties in 2008. I do not personally think we should necessarily promote them for other uses.

I am on break as of this afternoon, so responses in this thread may be delayed...

[tombaker]

@kcoyle

I'm not terribly bothered by dct:coverage with dct:temporal and dct:spatial as subclasses. I see no need to remove dct:coverage,

There might indeed be other good reasons not to remove dct:coverage from "the core", but if we are actively steering people towards using the subproperties, perhaps we should at least add those to the core.

[HughP]

that does not constitute a description of the model. For DC 1.1 in a sense there was no model, or at least it was a very very simple model

I would like to suggest that for analysis purposes that there is in fact an implied model. This model has several dimensions of description including: contributing agents, time, essence, about-ness, summary, and association . But also more so that full DCT model is not actually incompatible with the WEMI approach. The 1-to-1 principle does force some description requirements. It is this model which might become a useful lense of analysis when evaluating potential additions to the DCT or changes in DC 1.1. E.g., endorsed application profiles. For example, when considering the 1-to-1 model and pre/post-prints certain terms in the DC-SRAP do not make sense: dateSubmittedAsPreprint and dateSubmittedAsPostprint. These two terms ought to be simply dateSubmitted and then the record for the manifestation of the pre/post-print appropriately linked to the record for the manifestation which is the authoritative print version. If these are linked via a WEMI expression record rather than a manifestation-to-manifestation relationship is a matter of record keeping model employed by the institution. However, rather than having the SRAP proposed additional date elements (presumably added to the DCT namespace). It seems to me that additional relationships supporting WEMI relationships such as M:M and W:E relationships along with a genre focused element would solve many more use-cases than the specific terms in the SRAP proposal.

Maybe a useful exercise is to take the IFLA-LRM and map the entities of DC 1.1 and DCT to the various entities in that model, to provide a sort of "gap" analysis — how far can one get towards the IFLA-LRM with DCT? In my work I find the lack of relationships in DCT to be the most constraining omision, but I think there might be ways around this in some cases. For example, a Preprint has an isReplacedBy relationship with an manifestation of record where the Manifestation of record has a more current date while a post-print has an isReplacedBy relationship with the manifestation of record where the post-print has a more recent date.

I am less disturbed by DC 1.1 usage of coverage because in the OAI-PMH usage it is still very useful. The unused agent element in DC 1.1 is "cruft". More useful than adding spatial or temporal to the 1.1, would be to add a genre based element as DCMIType speaks to Mode, rather than genre specifically. Outside of genre identifier and contributor have no overtly declared modifiers such as LCSH is for subject. I think schema.org has a list of possible identifiers, but identifiers I use regularly include: URI, URL, ISBN, ISSN, DOI, LCNAF, and ORCID. If these types of additions are considered then I think it would be useful as a method of analysis when considering changes to have a systematic approach to work through implications by DCMIType vocabulary term. For example, if a DCT vocabulary were to be endorsed for identifier then rather than adding some adhoc identifier vocabularies as could appear to have been done for subject, think through implications for records where DCMIType event has been used, or records where DCMIType service has been used. My suspicion has been that many of the giants whose shoulders we stand on were well versed in thinking about artifact description where DCMIType was set to text but less attention was paid other parts of the vocabulary and the needs for description when those DCMITypes were invoked.

While not publication eloquent, I muse about DC on my blog in the following locations:

• https://hughandbecky.us/Hugh-CV/post/dublin-core-challenges/
• https://hugh.thejourneyler.org/2022/dublin-core-subject-field/
• https://hughandbecky.us/Hugh-CV/post/dublin-core-theory/

[HughP]

@tombaker @kcoyle

we are already steering people away from DC contributor

Can someone point me to the historical situation where dc:creator was discouraged while the dc:contributor was encouraged?