DC was massive in museums in the 90s. I think there are still remnant uses today - stuff like schema is a good reason for thinking about on-page metadata and dc was a part of that.<p>I was involved with a gov / lottery funded series of projects called “New Opportunities Fund” [0] which mandated DC markup. The exciting idea for us at the time was that we’d be able to create simple cross-site searchable assets. So we (I was at The Science Museum at the time) could create our project with 30k museum records in it, the NHM could make theirs and then ultimately someone could make a “portal” (ah, the 90s phrases are flooding back…) where users could search across all the NOF funded sites.<p>To the best of my knowledge the portal part was never made - we all did the dc bit but nothing global emerged from NOF.<p>There is (to this day) a conversation about how to allow this sort of interop across museum data. On the one side are SemWeb types, on the other lightweight microformat types. I’m massively over simplifying - but this is sort of how it goes.<p>I’ve always been fairly much in the latter camp. DC and microformats are incredibly crude - when you say an object has a “date” for example it clearly needs qualifying. Date it was made? Found? Used? Bought? Etc… - BUT to me it’s better to have this crude description than the alternative which is some kind of deeply complex (and thus never to be agreed / implemented across tens/hundreds/thousands of museums) sort of “perfect” standard.<p>Of course nowadays much of this is made irrelevant by good search, and the way the majority of people search the web. A general audience doesn’t actually want to search for all paintings made by x artist on y date - and when they do they’re content (for good or bad) to settle with Google results. And I guess AI will help. Maybe.<p>There are still a lot of data interop projects in museums and cultural heritage - stuff like the Museums Data Service [1] is brand new, TANC [2] has been going a while - and many more out there.<p>[0] <a href="https://www.gov.uk/government/organisations/new-opportunities-fund" rel="nofollow">https://www.gov.uk/government/organisations/new-opportunitie...</a> [1] <a href="https://museumdata.uk/" rel="nofollow">https://museumdata.uk/</a> [2] <a href="https://www.nationalcollection.org.uk/" rel="nofollow">https://www.nationalcollection.org.uk/</a>
I first encountered Dublin Core when I was working at a big university library. My take was it was an embarrassment compared to the 1970 MARC standard<p><a href="https://en.wikipedia.org/wiki/MARC_standards" rel="nofollow">https://en.wikipedia.org/wiki/MARC_standards</a><p>that it was more of what you'd expect from an elementary school library as opposed to a university library. Specifically it never implemented a way to (1) use authority records and (2) specify the order of the authors. It was the kind of thing that wrecked people's perception of "the semantic web" before it even got started.
I only knew of Dublin Core as it relates to image metadata. I was told it was popular among photo-journalists (it has tags: publisher, keyword, creator). The more nerdy EXIF metadata is what the camera often provides and tells you about <i>how</i> the image was taken (f-stop, shutter speed), not <i>who</i> or <i>what</i>.
Well it still just got my eye twitching.<p>Not really Dublin core itself, it is one of the more sedate ontologies.<p>But to keep up with the pack they did err, refine and expand into "terms" and "elements" but not cleanly so we will forever have the same labels for
nodes in different Dublin core name spaces.<p>You can have academic reasons till the cows come home but the bottom line is:<p><pre><code> You had one job.
</code></pre>
```<p><pre><code> The four DCMI namespaces are:
http://purl.org/dc/elements/1.1/ The /elements/1.1/ namespace was created in 2000 for the RDF representation of the fifteen-element Dublin Core and has been widely used in data for more than twenty years. This namespace corresponds to the original scope of ISO 15836, which was published first in 2003 and last revised in 2017 as ISO 15836-1:2017 [ISO 15836-1:2017.
http://purl.org/dc/terms/ The /terms/ namespace was originally created in 2001 for identifying new terms coined outside of the original fifteen-element Dublin Core. In 2008, in the context of defining formal semantic constraints for DCMI metadata terms in support of RDF applications, the original fifteen elements themselves were mirrored in the /terms/ namespace. As a result, there exists both a dc:date (http://purl.org/dc/elements/1.1/date) with no formal range and a corresponding dcterms:date (http://purl.org/dc/terms/date) with a formal range of "literal". While these distinctions are significant for creators of RDF applications, most users can safely treat the fifteen parallel properties as equivalent. The most useful properties and classes of DCMI Metadata Terms have now been published as ISO 15836-2:2019 [ISO 15836-2:2019]. While the /elements/1.1/ namespace will be supported indefinitely, DCMI gently encourages use of the /terms/ namespace.
http://purl.org/dc/dcmitype/ The /dcmitype/ namespace was created in 2001 for the DCMI Type Vocabulary, which defines classes for basic types of thing that can be described using DCMI metadata terms.
http://purl.org/dc/dcam/ The /dcam/ namespace was created in 2008 for terms used in the description of DCMI metadata terms.
```</code></pre>
Dublin Core is the main metadata schema for many institutional repositories, for example the DSpace platform <a href="https://github.com/DSpace/dspace">https://github.com/DSpace/dspace</a>. The schema essentially only covers basic bibliographic metadata and has a strong pre-digital library feel to it. We end up augmenting with other custom schemas to be able to describe content in our repository, for example podcasts and journal articles with different issue and online dates, as well as extra metadata like author affiliations, funders, internal programs etc.
Omeka-S[1] is an open source publishing platform (for museums, libraries, artifact collections etc) that has first class support for Dublin Core.<p>Dublin Core “clicked” for me when we started using it in Omeka to publish a collection of digitised books online[2].<p>- <a href="https://omeka.org" rel="nofollow">https://omeka.org</a><p>- <a href="https://gpura.org" rel="nofollow">https://gpura.org</a>
A summary: it's a successfully failed idea we can reach a day something like semantic search thanks to carefully written metadata, or we can classify anything to make anything easy to retrieve as a single information atom (a book, a report, a map) or even inside it finding just the bit of information we look for not in a single atom but across many.<p>Another Library of Babels/Biblioteca universalis by Conrad Gessner (~1545). Unfortunately while in theory the system could work we can't ensure anyone use is WELL in practice and just some metadata to classify anything in a coherent way it's far from being enough.<p>DC was an immense diplomatic effort in library science still with a damn limited practical outcome.
EPUB (even v3) uses some Dublin Core metadata. Unlike the page the thread refers to it's presented as `<dc:title>` not `DC.Title` but other than that it's the same thing. Only a handful of tags are used.<p><pre><code> https://idpf.org/epub/30/spec/epub30-publications.html#sec-metadata-elem</code></pre>