Lady’s Gitweb - Vocab/blob - data/named_individuals/_DCMI_

   1 <?xml version="1.0"?>
   2 <!--
   3 SPDX-FileCopyrightText: 2024 Lady <https://www.ladys.computer/about/#lady>
   4 SPDX-License-Identifier: CC0-1.0
   5 -->
   6 <!DOCTYPE NamedIndividual SYSTEM "../../DTD">
   7 <NamedIndividual name="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/">
   8         <label xml:lang="en">D·C·M·I Metadata Terms</label>
   9         <comment xml:lang="en">
  10                 <p>
  11                         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.
  12                         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.
  13                         Not every aspect of the model has stood the test of time, but core terms like <ptr target="dcterms:title"/> are indispensible.
  14                 </p>
  15                 <p>
  16                         D·C·M·I defines four different name·spaces.
  17                         Of these, <code>dcterms:</code> and <code>dcmitype:</code> are the straightforwardly useful as documented.
  18                         The <code>dcam:</code> name·space is not really useful at all, as much more sophisticated solutions to its problem space exist.
  19                 </p>
  20                 <p>
  21                         The <code>dc11:</code> name·space requires more careful consideration.
  22                         Each term in the <code>dc11:</code> name·space is duplicated in the <code>dcterms:</code> name·space, and in general the latter is recommended.
  23                         However, the <code>dcterms:</code> name·space is not use·able in all cases, especially within an Owl ontology.
  24                         For example, <resource name="dcterms:language"/> is defined with a range of <resource name="dcterms:LinguisticSystem"/>.
  25                         One might consider <resource name="dcterms:LinguisticSystem"/> to be an Owl Class of objects, and consequently <resource name="dcterms:language"/> to be an object property.<note n="1">
  26                                 <p>
  27                                         This is the interpretation that this ontology makes, but it is not the only valid one.
  28                                         <resource name="dcterms:LinguisticSystem"/> could instead be a Datatype, requiring <resource name="dcterms:language"/> to take only Literal values, not objects.
  29                                         A third option, where <resource name="dcterms:LinguisticSystem"/> encompasses both objects and literal values, is hypothetically possible but not practically realizable in Owl.
  30                                 </p>
  31                         </note>
  32                         This interpretation means <resource name="dcterms:language"/> cannot be used as a data property or take data values, such as <resource name="xsd:language"/>s.
  33                         Yet <resource name="dc11:language"/>, which has no defined range in D·C·M·I, can be defined as a data property instead,<note n="2">
  34                                 <p>
  35                                         If one ignores the subproperty definitions provided in the D·C·M·I specification.
  36                                         Actually, D·C·M·I defines all <code>dc11:</code> terms as superproperties of their <code>dcterms:</code> counterparts—implying, under Owl semantics, that they are of the same type.
  37                                         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.
  38                                         Keeping <code>dc11:</code> properties of the same type as <code>dcterms:</code> 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.
  39                                 </p>
  40                         </note> and accept the values that <resource name="dcterms:language"/> cannot.
  41                 </p>
  42                 <p>
  43                         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.
  44                         It tries to do so in the most broadly‐compatible, uncontroversial way for those terms in the <code>dcterms:</code> name·space.
  45                         It then takes the opposite position for terms in <code>dc11:</code>, with the assumption that data which is not using the <code>dcterms:</code> name·space is refusing to do so with good reason.
  46                         Neither of these positions are incontrovertible, and not all R·D·F graphs will conform to them.
  47                         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.
  48                 </p>
  49                 <p>
  50                         Because of their ubiquity, all terms from <code>dc11:</code>, <code>dcterms:</code>, and <code>dcmitype:</code> are given definitions in this ontology, regardless of perceived utility, with the following exceptions :⁠—
  51                 </p>
  52                 <list>
  53                         <item>
  54                                 <p>
  55                                         <resource name="dcterms:AgentClass"/>, and the properties which have it as their range (<resource name="dcterms:audience"/>, <resource name="dcterms:educationLevel"/>, <resource name="dcterms:mediator"/>).
  56                                         The use of <resource name="dcterms:AgentClass"/> as both a class (of which <ptr target="dcterms:Agent"/>s are instances) and an object isn¦t problematic ⅌·se, but this kind of metamodelling is not really bestpractices anymore.
  57                                         It is better to model kinds of agents as a <em>role</em> which agents (or qualified agents) <em>possess</em> rather than a <em>type</em> which they <em>have</em>; in general, typing information is not useful for grabbag qualifications on objects, but rather as a mechanism for qualifying or contextualizing the <em>properties</em> which an object has.
  58                                 </p>
  59                         </item>
  60                         <item>
  61                                 <p>
  62                                         Vocabulary encoding schemes, as they depend on <code>dcam:</code> and <ptr target="(SKOS)"/> is a better solution.
  63                                 </p>
  64                         </item>
  65                         <item>
  66                                 <p>
  67                                         Syntax encoding schemes, i·e datatypes.
  68                                         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:
  69                                         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.
  70                                 </p>
  71                         </item>
  72                 </list>
  73         </comment>
  74         <type>
  75                 <resource name="dcterms:BibliographicResource"/>
  76         </type>
  77         <type>
  78                 <resource name="dcterms:Standard"/>
  79         </type>
  80         <type>
  81                 <resource name="foaf:Document"/>
  82         </type>
  83 </NamedIndividual>