The Dublin Core Metadata Initiative (D·C·M·I) metadata terms (i·e, the Dublin Core vocabulary) are some of the earliest attempts at standardizing metadata encoding on the Web. Because of their age and association with library science (the “Dublin” is Dublin, Ohio, the headquarters of O·C·L·C), these terms are widely used and referenced both in metadata resources themselves and in other specifications which describe them. Not every aspect of the model has stood the test of time, but core terms like are indispensible.

D·C·M·I defines four different name·spaces. Of these, dcterms: and dcmitype: are the straightforwardly useful as documented. The dcam: name·space is not really useful at all, as much more sophisticated solutions to its problem space exist.

The dc11: name·space requires more careful consideration. Each term in the dc11: name·space is duplicated in the dcterms: name·space, and in general the latter is recommended. However, the dcterms: name·space is not use·able in all cases, especially within an Owl ontology. For example, is defined with a range of . One might consider to be an Owl Class of objects, and consequently to be an object property.

This is the interpretation that this ontology makes, but it is not the only valid one. could instead be a Datatype, requiring to take only Literal values, not objects. A third option, where encompasses both objects and literal values, is hypothetically possible but not practically realizable in Owl.

This interpretation means cannot be used as a data property or take data values, such as s. Yet , which has no defined range in D·C·M·I, can be defined as a data property instead,

If one ignores the subproperty definitions provided in the D·C·M·I specification. Actually, D·C·M·I defines all dc11: terms as superproperties of their dcterms: counterparts—implying, under Owl semantics, that they are of the same type. While this isn¦t formally impossible (properties serving dual roles as both data properties and object properties is not inconsistent), it is impossible to reason about effectively. Keeping dc11: properties of the same type as dcterms: negates the utility of having the two name·spaces and doesn¦t match actual usage in the wild, so this ontology simply ignores the subproperty relationships between the two.

and accept the values that cannot.

The actual definitions of the D·C·M·I terms do not have an unambiguous mapping into Owl, but this ontology is forced to take a stance as to what such a mapping would be. It tries to do so in the most broadly‐compatible, uncontroversial way for those terms in the dcterms: name·space. It then takes the opposite position for terms in dc11:, with the assumption that data which is not using the dcterms: name·space is refusing to do so with good reason. Neither of these positions are incontrovertible, and not all R·D·F graphs will conform to them. But this is the best that can be done for a set of name·spaces which are foundational to so many internet standards and yet themselves so loosely‐specified.

Because of their ubiquity, all terms from dc11:, dcterms:, and dcmitype: are given definitions in this ontology, regardless of perceived utility, with the following exceptions :⁠—

, and the properties which have it as their range (, , ). The use of as both a class (of which s are instances) and an object isn¦t problematic ⅌·se, but this kind of metamodelling is not really bestpractices anymore. It is better to model kinds of agents as a role which agents (or qualified agents) possess rather than a type which they have; in general, typing information is not useful for grabbag qualifications on objects, but rather as a mechanism for qualifying or contextualizing the properties which an object has.

Vocabulary encoding schemes, as they depend on dcam: and is a better solution.

Syntax encoding schemes, i·e datatypes. The use of datatypes beyond the core X·S·D and R·D·F set on literals for indicating the format of the literal data is an idea from early in R·D·F development which hasn¦t withstood the test of time: Such datatypes can¦t typically be reasoned about, or constrained, and offer little over plain string typing in a qualified relation that also indicates the type of data.