Tom, Stu:

Thank you for initiating this discussion.  Please see my questions
throughout.  Hope they are helpful.  I have indicated my comments with
square brackets.

--Erik

Process for [Dublin Core?] Qualifiers: A Proposal

Thomas Baker and Stuart Weibel

Version 2.1



I. Guidelines for Proposed and Recommended Interoperability Qualifiers:

[It strikes me, after reading this document several times, that there are
three categories of Dublin Core qualifiers: (1) registered, (2) proposed,
and (3) recommended.  Should this document treat them in that order?


    a. Qualifiers should refine, not extend, element semantics
       (Canberra).

    b. A means for extracting an unqualified value from a qualified
       value should be either implicit or explicit in the expression of
       the value (the Dumb-down rule).

["Either implicit of explicit" seems to cover everything.  If I were to read
this from the point of view of a potential implementor, I am not sure that I
would know what to do based on this instruction.]

    c. An application that wants to deploy structured extensions
       should do so by referencing a public schema for that extension
       (eg, an authority file, a vCard structure).

[In Ia., above, it is stipulated that qualifiers do not extend.  Yet here
you are talking about "structured extensions."  What is a structured
extension and why is it allowed, if qualifiers do not extend.?  Also, what
is a "public schema"?  As a reader of this document, how am I to know what
you mean by this term?  Can you point me to a reference or include a
definition?  How is the public schema to be referenced?  Can I choose the
manner of reference?  If not, where am I to find specific instructions?]

    d. Adopt existing qualifiers when possible (ie, avoid 
       reinventing wheels).

[How about "use" instead of "adopt"?]

    e. Provide rigorous and understandable definitions.

[How is "rigor" defined or determined?  And by whom?]

    f. Specialized, community-specific qualifiers should be defined in
       separate namespaces; the DC namespace should be reserved
       for qualifiers of general interest across disciplines.

[What is a namespace?  Can you point me to a reference or provide a
definition?  You specify "general interest across disciplines" as the
criterion.  Elsewhere in this document you provide other criteria.  Does
this stipulation mean that "specialized, comunity-specific qualifiers" are
excluded from the processes described in this document, sinced they are
registered in other namespaces which are, I presume, under the control of
others?"]


    g. Demonstrable utility in existing applications increases the
       likelihood of recommendation.

[Would that "demonstrable utility" were easy to define!  If a community
says, "we use this," is that enough?  Also, this paragraph presumes some
sort of promotion or preferential state, that is, "recommendation."  Yet the
definitions and sequencing of "registered," "proposed," and "recommended"
have not yer been introduced in this document.]

    h. Qualifiers that violate some aspects of these principles
       but that nevertheless are widely used (arguably providing
       thereby some measure of interoperability) should be 
       considered on a case-by-case basis.

[Giant excape clause. Does not seem meet the earlier requirements for
rigor.] 

II. Registry of Dublin Core

[Insert basic definition of "registry"?  And, there is a defference between
a registry (a thing) and registration (a process).  If you are givng process
instructions, should you provide them under a heading like "How to Reigster
an Element, Qualifier, or Schema]

    A. The registry will hold a database of
    elements and qualifiers that includes:

[The registry "holds" a database?  Is it a database.  Something else plus a
database?  Given the title of this document, I would not expect to find a
discussion of the registry of elements.  Is that treated, or to be treated,
elsewhere?]

        1.  A URI identifier for each entity (element,
        qualifier, or structured schema).

[What is a "structured schema"?}

        2.  For each qualifier, a unique token represented in 
        the Latin-1 character
        set (assigned by the DC Directorate under advisement of
        the DC Usage Committee).

[Need for some definitions or references here?  What do you mean by "token"?
Where is the "" defined?]

 
        3.  A name and definition for each qualifier in a 
        language chosen by
        the proposing individual, agency or group.

        4.  Optionally, a name and definition for each qualifier
        in English (required only for Proposed 
        Interoperability Qualifiers).

[Why not required for elements?]

    B. The purposes of this registry include:

        1.  Formal management of the DC namespace for elements
        and qualifiers by the DCMI.

[But not schema?]

        2.  Public discovery of known DC elements by humans
        (users, schema designers, metadata implementers, usage
        reviewers).

        3.  Machine-readable schema retrieval by metadata
        applications.


III. Process for the registration and endorsement of qualifiers

    A. A Dublin Core element qualifier or Dublin-Core-based schema 
       may be registered by making that qualifier or schema 
       available on the Web in RDF schema format.  To help users
       with RDF, a Web form will be made available for generating
       such schemas automatically.
       Registration provides a record of activity for the
       collective benefit and does not imply endorsement by
       DCMI.

[What is this the nature of this record of activity?  Is mere registration
the record?]

    B. Any Registered Qualifier may be proposed for promotion
       to the status Proposed Interoperability Qualifier by providing a
       name (label) and definition (description) in clear English
       -- again, via a Web form.  A DCMI Usage Committee will evaluate
       the proposed qualifier against the Guidelines for Interoperability
       Qualifiers.  Qualifiers judged by at least two thirds of the
       Usage Committee to substantially meet these formal
       criteria will be assigned a global interoperability token.

    C. The DCMI Usage Committee will periodically ratify the 
       promotion of Proposed Interoperability Qualifiers to the status
       of Recommended Interoperability Qualifiers.  To qualify for
       promotion, such a qualifier should be demonstrated to be of broad
       interest -- for example, by adoption by five or more independent
       applications in three or more domains or sectors.  

[This seems a little too vague, but maybe you want it to be.  My sense is
that it is better for for people to know the ground rules more precisely.]

--Erik

Erik Jul
[log in to unmask]


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%