Note: originally posted as:
http://www.mailbase.ac.uk/lists/dc-datamodel/files/decisions.html
with date 1999-03-20.  The decisions date from a 1998-09-24 Data
Model Working Group meeting at ECDL in Heraklion, Crete.

                    Dublin Core Data Model Working Group

                               Decisions


      Contents
      --------
      1   Process
      2   General
      3   Qualified DC
      4   Namespaces, specifications, URIs and naming
      5   Repetition
      6   Interoperation between DC-Simple and Qualified-DC systems
      7   RDF Schema
      8   Multilingual strings
      9   Element-specific points
      10  Miscellaneous
      11  Informative Annex A -- Element Qualifier(s) for dc:Title

1     Process
      -------

1.1   The draft spec will include explicit mention that it is only a 
      draft and that element-specific WGs are invited to review it and 
      comment on it, especially on the element-specific aspects.

2     General
      -------

2.1   The DC community will "borrow or steal" from other communities 
      where reasonable.  This applies in particular to terminology, 
      schemas, vocabularies etc.

2.2   The RDF data model is the foundation for the DC data model.  This 
      does not mean that DC (qualified or unqualified) must be expressed 
      in RDF or even in XML.  These langauges do, however, offer us 
      powerful modelling tools, which we are glad to make use of.

2.3   The value of each of the DC elements may be a string or a URI.  
      The URI may be either the URI of an RDF node or a URI which should 
      be resolved in order to obtain a value.

3     Qualified DC
      ------------

3.1   Qualified DC adds three tools to the toolbox provided by 
      unqualifed DC.  These are:

      -  Value Qualifiers, which allow us to correctly interpret string 
         values.

      -  Element Qualifiers, which allow us to make statements such as 
         "X is a Y".

      -  Value Components, which allow us to make statements such as 
         "X has a Y".

      The first two of these are referred to as "Qualifiers".  All three 
      are further discussed below.

      In addition to the above three tools, RDF provides very useful 
      constructs for the grouping and sequencing of statements.  These 
      constructs (Seq, Alt, Bag) may be used for both qualified and 
      unqualified DC.

      DC delegates the handling of language qualification to RDF and XML.

3.2   A Value Qualifier:

      -  Qualifies a string value and can be applied only to string 
         values.

      -  Defines either an encoding scheme, or a controlled vocabulary.

      -  Is expressed using the machine-readable token "xyz:Scheme" 
         (where "xyz" is the local abbreviation for the "dcq" namespace).

      -  Takes as a value either a string (eg "ISO-8601") or a URI 
         (eg "http://www.w3.org/TR/NOTE-datetime").

3.3   We consider that the following definition of Value Qualifiers is 
      broadly correct but will require further editing:

         A Value Qualifier refers to the value, specifying either an 
         encoding rule or a controlled vocabulary to aid in interpreting 
         the value.  Value Qualifiers apply only to strings, but may be 
         expressed as URIs.  Recommended practice is to use a Value 
         Qualifier generally understood by the target community, or a 
         standard encoding or parsing scheme in wide use across 
         communities.  Repetition of elements allows use of Value 
         Qualifiers from more than one source or at more than one level 
         of specificity.

3.4   We consider that the following definition of Element Qualifiers is 
      broadly correct but will require further editing:

         An Element Qualifier refines the semantics of a DC element to 
         further specify the relationship of the element to the resource 
         itself.  The Element Qualifier does not change the definition 
         of the element, nor does it modify the value.  Recommended 
         practice is to use an Element Qualifier from the DCQ controlled 
         list defined for that element or from a domain specific list 
         approved and maintained by a particular community.  Repetition 
         of elements allows use of terms from more than one source.

3.5   Each DC Element may have zero or more Element Qualifiers.

3.6   We consider that the following definition of Value Components is 
      broadly correct but will require further editing:

         Value Components are semantic characteristics (eg name, 
         haircolor, eyecolor, SSN, etc of a person) of a value.  These 
         characteristics may be drawn from existing vocabularies or 
         defined by local communities.  Value Components are intrinsic 
         to the value regardless of its relationship to a particular 
         resource.

3.7   We shall use the term "Intermediate Node" to denote a resource in 
      an RDF graph that does not have an independent existence in the 
      real world.

3.8   Element Qualifiers and Value Qualifiers are properties of a 
      structural node.  A single such structural node can have both an 
      Element Qualifier and a Value Qualifier, eg:

      Unqualified:

         [R1]---dc:Date------->"1998-12-31"

      Qualified:

         [R1]---dc:Date------->[IN1]
         [IN1]--rdf:Value----->"1998-12-31"
         [IN1]--dcq:DateType-->"http://....Issued"
         [IN1]--dcq:Scheme---->"http://www.w3.org/TR/NOTE-datetime"

4     Namespaces, specifications, URIs and naming
      -------------------------------------------

4.1   We shall use different namespaces for unqualified DC and for 
      qualified DC.

4.2   For the 15 DC elements defined in RFC 2413, the namespace we shall 
      use is:

         http://purl.org/dc/elements/1.0/

      We note that the portion:

         purl.org/dc

      may change in the future.

      The corresponding recommended abbreviation is "dc".  The use of a 
      common abbreviation improves readability.  Note, however, that the 
      actual choice of abbreviation is a local matter, as the namespace 
      is defined solely by a URI.

4.3   For the DC qualifiers, the namespace we shall use is:

         http://purl.org/dc/qualifiers/1.0/

      The corresponding recommended abbreviation is "dcq".  The use of a 
      common abbreviation improves readability.  Note, however, that the 
      actual choice of abbreviation is a local matter, as the namespace 
      is defined solely by a URI.

4.4   Some of the terms (eg IsBasedOn) to be used with DC qualifiers (eg 
      RelationType) will be defined by the DC community.  These will be 
      grouped into logically related sets of terms (eg the set of 
      Relation Types).  We shall define a namespace for each such 
      logically related set of terms (eg for the set of Relation Types).

      [Editorial note: The use of a separate namespace for each group of 
      terms is under review.]

4.5   We shall not include dots (or any other punctuation) in the names 
      of qualifiers.

4.6   The DC specifications will define lists of values for some of the 
      DCQ qualifiers (such as dcq:RelationType) though not for all such 
      qualifiers.  For some of the qualifiers for which we will define 
      lists of values, it will be open to other communities to define 
      additional values.  For those qualifiers for which we do not 
      define lists of values, all possible values will be defined by 
      other communities.

4.7   Referring to the point above, the values defined in the DC 
      specifications will be URIs 
      (eg "http:/purl.org/.../dublin.../...IsBasedOn").  We are not 
      imposing such a restriction on values defined by others.  That is, 
      in general, the value of an Element Qualifier or of a Value 
      Qualifier may be either a string or a URI.

4.8   Where the DC community specifies a list of values for a DC Element 
      (or Value Component), those values shall take the form of URIs.

4.9   Developers MUST not assume that all changes to DC-defined 
      vocabularies (lists of qualifier values or value values) will be 
      identified by changing the URI of the vocabulary.

4.10  We shall document unqualified and qualified DC in a single 
      (versioned) spec, while retaining the various distinct namespaces 
      with their own versions.  The spec version is for human 
      consumption.  The namespace versions are for machine consumption.
      Note that qualifiers are not guaranteed to be independent of the 
      version of the "dc" namespace.  The spec should incorporate the 
      notion of a migration path.

4.11  The "dcq" spec should include a non-normative section, containing 
      a statement such as "Developers of new vocabularies MUST state 
      whether any change to the vocabulary will be identified by 
      changing the URI of the vocabulary".

5     Repetition
      ----------

5.1   Multiple instances of a DC PropertyType may be expressed using 
      simple repetition or any one of the three RDF M&S collection 
      constructs (Bag, Seq and Alt).  The DC DM WG seeks feedback on 
      this decision from DC implementors.

5.2   Where multiple instances of a DC PropertyType are to be ordered, 
      the appropriate RDF M&S collection construct (Seq or Alt) should 
      be used.

5.3   The above decisions apply also to Element Qualifiers and to Value 
      Qualifiers (though we cannot see good uses for Alt in this case). 
      We seek feedback on this decision from DC implementors.

5.4   For the repetition and ordering of values we recommend the use of 
      a single rdf:value arc pointing to the appropriate one of the 
      three RDF collection constructs (Alt, Seq, Bag).  In some cases it 
      may be appropriate, instead, to repeat the entire DC element, with 
      the additional value.  Where values are provided in multiple 
      languages and there is no default language, we recommend use of a 
      Bag; if there is a default language, we recommend use of an Alt.  
      The DC DM WG seeks feedback on this decision from DC implementors, 
      particularly those working on multilingual DC.

6     Interoperation between DC-Simple and Qualified-DC systems
      ---------------------------------------------------------

6.1   A DC agent MUST understand the "dc" namespace and the RDF M&S 
      namespace (here shown as "rdf").  Understanding the "rdf" 
      namespace includes understanding how to extract unqualified DC 
      values from qualified DC constructs.

6.2   Every valid unqualified DC description is a valid qualified DC 
      description.  In other words, qualifier-capable DC systems can't 
      require the presence of qualifiers, they must be able to use 
      unqualified elements.

6.3   Qualifier-capable DC systems MUST not automatically add any 
      particular qualifier and qualifier value to incoming descriptions
      which lack them.  For example, don't automatically add 
      dcq:DateType="...Created" to any incoming dc:Date element.

6.4   Conversion from a qualified-DC description to a simple DC 
      description is accomplished through the standard procedure given 
      below:

      // dumb-down(Element)
      // Returns a string that is the Simple DC version of the qualified
      // DC description, Element.
      // The gist of the procedure is to ignore all qualifiers that
      // originate at structural nodes, and follow the chain of
      // rdf:value arcs until a String is found. That string is returned
      // as the value of the procedure. For example,
      //   [resource]---dc:Title--->[sn01]
      //   [sn01]---dcq:TitleType--->"alternative"
      //         ---rdf:value--->"Paris Symphony"
      // would simplify to
      //   [resource]---dc:Title--->"Paris Symphony"
      //
      // The expected invocation of the procedure is in a loop like:
      //   For each (qualified) dc element in a description
      //       currentArc = the arc of the DC element
      //       string = dumb-down(currentArc);
      //       replace qualified value of DC element with string
      //      (if its a null string, then don't specify that DC element)

      procedure dumb-down(theArc) returns a string {
         if (theArc points to a string)
            return that string
         else if (theArc points to a structural node with an rdf:value 
            arc)
            return dumb-down(the rdf:value arc from that node)
         else if (currentArc points to a node of 'known' type)
            // e.g. a vCard node
            handle it in the manner appropriate for that known type
            (this will either return a string or call dumb-down with
            some arc emenating from that node)
         else if (currentArc points to a Bag)
            tempString = null
            for each member arc j from the bag
               // member arcs are the _1, _2,... arcs
               tempString += dumb-down(j);  // += means concatenation
         else if (currentArc points to a Seq)
            tempString = null
            for each member arc j from the seq
               tempString += dumb-down(j);  // += means concatenation
         else if (currentArc points to an Alt)
            pick one  member arc, using the default (first) arc if
            you have no particular reason to pick another.
            return dumb-down(the chosen arc)
         else (currentArc points to a node of unknown type)
            return a null string
            // The alternative of mindless concatenation is not
            // recommended.
      }

7     RDF Schema
      ----------

7.1   Element Qualifiers are all instances of a class named something 
      like dcq:ElementQualifier.  Value Qualifiers and Value Components 
      may be able use a similar approach.

7.2   The WG has decided that an isDefinedIn property is necessary and 
      will request that the RDF Schema WG provide such a property.  
      Failing this, the WG will specify such a property.

8     Multilingual strings
      --------------------

8.1   The DC community requires the ability to handle multilingual 
      strings, associating each sub-string with its language.  Language 
      qualification of an entire string is just a degenerate case of 
      this requirement.  Hence, the functionality of the Canberra 
      language qualifier (which applied to entire strings) is satisfied 
      by XML's xml:lang attribute.

8.2   The DC DM WG asks the XML, I18N and HTML WGs of the W3C to provide 
      a general mechanism for multilingual strings in XML documents.

8.3   The DC DM WG asks the W3C RDF M&S WG to support the above 
      mechanism once it has been specified.

9     Element-specific points
      -----------------------

9.1   An Element Qualifier for the dc:Contributor, dc:Creator and 
      dc:Publisher elements, which qualifies those elements by 
      specifying the contributory role, is dcq:AgentRole.  Feedback from 
      the relevant WG(s) is requested.

9.2   An Element Qualifier for the dc:Relation element, which qualifies 
      that element by allowing a more specific relation to be given, is 
      dcq:RelationType.  Feedback from the Relation WG is requested.

9.3   An Element Qualifier for the dc:Date element, which qualifies that 
      element by allowing a more precise specification of the type of 
      the date, is dcq:DateType.  Feedback from the Date WG is requested.

9.4   Additional qualifiers will be added over time, via the DC process.

9.5   The semantic purpose of a dc:Identifier is satisfied by the 
      Resource's own URI.

9.6   We recommend that agents (dc:Creator, dc:Contributor and 
      dc:Publisher) be described in any of the following ways:

      -  using a string to hold the agent's name,

      -  using in-line RDF from other appropriate namespaces (eg vCard 
         or LCNAF) once use of such RDF has been sanctioned by the 
         organisations owning the particular standards (eg vCard or 
         LCNAF),

      -  using a URI to point to a remote name file (which uses vCard 
         or LCNAF etc).

9.7   The Personal vs Corporate (etc?) nature of a value is expressed 
      using the rdf:Type property if the value is a node.  The DC 
      community will develop a controlled vocabulary incorporating at 
      least terms representing a person and a corporate body.

10    Miscellaneous
      -------------

10.1  In RDF, we use only DC element names as the names of properties of 
      nodes which represent actual resources.  In other words, at the 
      outermost level, we do not use any property names other than the 
      fifteen DC element names.

10.2  In RDF, we do not use the fifteen DC element names except as the 
      names of properties that apply to actual resources.  In other 
      words, at inner levels, we do not use the fifteen DC element names 
      to name properties.

11    Informative Annex A -- Element Qualifier(s) for dc:Title
      --------------------------------------------------------

11.1  An Element Qualifier for the dc:Title element, which qualifies 
      that element by allowing a more precise specification of the 
      structure (eg Main, Alternative) of the title, might be 
      dcq:TitleStructure.

      An example of another possible Element Qualifier for dc:Title 
      might be dcq:TitleExpression, whose values might be, eg, 
      Original, Transliterated, Translated, etc.

      Feedback from the Title WG is requested, covering:
      a) the need for each qualifier,
      b) the semantics of each qualifier,
      c) the machine-readable token representing each qualifier,
      d) the DC-defined values of each qualifier (if any).