innovation in metadata design, implementation & best practices

Title: Other (mostly old) issues
See also:
Created: 2004-09-14
Agenda frozen: 2004-10-02 07:25, Saturday
Archived: 2004-11-10
Maintainer: Tom Baker
Note: If any of the links below are broken, please refer to 
                   the meeting packet
                   for copies of the key documents discussed at the meeting.

This is a grab-bag of issues which were at one time pointed
out, have (probably) not been resolved, but are not urgent
enough to push.

== Definition of dc:title. The definition of "title" should
    be reworded to eliminate an inherent assumption that a
    resource must have a well-defined, unique, formal title.
    (Roland, Oct 2001)

== Qualification of dc:format. As proposed in 1999, the
    Format qualifier "medium" is only applicable to physical
    resources and "IMT" is only applicable to virtual
    resources. Do we need to revise the official definitions
    to clarify something like the following? (Andy, Feb 25
    2002) :
    1) genre - the representational class of the resource
    2) medium - the physical carrier of the information
    3) encoding - the way in which the data is encoded on the
       medium (DC.Format/IMT)

== RDDL Core. RDDL in effect defines its own core element
    set for resource discovery -- one that overlaps in awkward
    ways with Dublin Core. See
    and Is this
    a problem? (Oct 2001).

== Use of Dublin Core for non-DLO resources. Is it acceptable
    to use DC metadata to describe non-DLOs (such as people,
    organisations, museum artefacts, events, hurricanes,
    species)? Or: does DCMI want to say that it is *not*
    acceptable to describe these kinds of things using DC
    metadata? (Andy, Jan 2002; Liddy Nevile in Dec 2002)
    Diane thinks it's useful to have a consensus on this, but we
    might want to have someone write a discussion starter couple
    of pages on this before we meet; there's a lot of history
    to this one.

== DCMI Type Vocabulary and Dublin Core scope. If DCMI
    wants to say that it is *not* acceptable to describe
    non-DLOs using DC metadata, do we need to indicate
    somehwere that the current DCMI Type list is _not_ intended
    to be an exhaustive list of the kinds of resources that DC
    can be used to describe? To what extent is the current
    list of types in the DCMIType list an exhaustive list
    of the kinds of resources that can be described using
    DC metadata? (Andy, Jan 2002)

== Guidelines on using Dublin Core for non-DLO resources.
    If it is acceptable to describe non-DLOs using DC metadata,
    does DCMI want to provide any best-practice guidelines for
    how to do it in specific instances, such as for people?
    If so, what DCMI WGs would do this? (Andy, Jan 2002)

== Encoding schemes for dc:relation and dc:source. Should all
    encoding schemes for Identifier hold also for Relation and
    Source? Do we need to capture this in our documentation?
    Diane thinks we should first agree whether we want to do
    something similar to the creator/contributor thing as a
    precursor to considering this question.

== Scope of dc:language. Language should not be restricted
    to natural languages. Languages in the sense of computer
    science can carry intellectual content, but the "best
    practice" assertion seems to exclude that (Roland,
    Oct 2002).

== Comment for dc:subject. The Comment for dc:subject could
    be read as condoning usage such as
    "<dc:subject>252</dc:subject>". Roland strongly disagrees
    with this and thinks it needs clarification (Roland,
    Oct 2002). The comment currently reads:

       Typically, a Subject will be expressed as keywords,
       key phrases or classification codes that describe
       a topic of the resource. Recommended best practice
       is to select a value from a controlled vocabulary or
       formal classification scheme.

== Applicability of encoding schemes to Element
    Refinements. According to the term declaration, W3CDTF and
    Period only apply to Date, not any of the Date refinements.
    Should they apply to Date AND all its refinements (both
    recommended and conforming)? Diane points out that this 
    is really the same question as in Source and Relation.

== 2002-11-05: Relationship between
    dc:contributor/1.0 and dc:contributor/1.1

== Should DCMI use the term 'application profile' to describe
    sub-sets of its vocabulary? Arguments "contra": An
    application profile 'uses' standard terms in an optimised
    way for a particular application; there are an infinite
    variety of application profiles that could be constructed.
    DCMI has said it is not in the business of 'approving'
    an unlimited number of application profiles. DCMI
    recommendations need to advise on 'generic' use of DCMI
    terms. Should we 'approve' particular application profiles
    which may well emerge in a fairly arbitrary way? How will
    DCMI distinguish between application profiles it wants
    to consider in the approval process and those it does not??

== The OASIS DocBook Candidate Release
    makes a point of being compatible with Dublin Core _1.0_:

== "Related to this, I know the IMT encoding scheme is only valid
    for the Format element and not the medium element refinement
    [1]. Do we have a similar issue with W3CDTF - the schema
    makes it valid only for Date and temporal, but not any of the
    Date element refinements (created, et. al.). I guess this is
    a reflection of how the usage of W3CDTF is defined in the DC
    Terms documents. Though, looking back at the DC Qualifiers
    document, it wasn't clear whether an encoding scheme valid
    for an element is also valid for its element refinements -
    as discussed [1] IMT isn't intended for use in medium but
    surely W3CDTF is intended for use in created, modified, etc.?

== Carol van Nuys of the Norwegian Nasjonalbiblioteket
   had trouble translating the comment for Alternative
   (Title), which reads: "This qualifier can include Title
   abbreviations as well as translations." She assumes that
   it is the *value* of the qualifier which can include Title
   abbreviations, but the wording is a bit imprecise and,
   to some people, seems to actually say something else.

== Status and documentation of DCMES 1.0 elements:
   Shows identifier as being,
   which does in fact resolve to DCMES 1.0 document.
   Also, the DCMI Metadata Terms document does not show
   1.0 terms (but neither did current-elements document).
   Term-History (not yet available) shows 1.1 elements replacing 1.0.
   Likewise, "replaces"
   (actually supersedes)