Title:         Usage Board meeting in Seoul - 2009-10-16 - Meeting notes
Identifier:    http://dublincore.org/usage/minutes/2009/2009-10-16.dcub-meeting-seoul-minutes.html
Created:       2009-11-14

Attended: Tom Baker (chair), Akira Miyazawa, Andrew Wilson, Joe Tennis, 
          Julie Allinson (remote by Skype), Pete Johnston (remote by Skype), Stefanie Ruehle,
          Makx Dekkers (first hour, ex officio)

Guests:   Raju Buddharaju

Agenda:   http://dublincore.org/usage/meetings/2009/10/seoul/
Packet:   http://dublincore.org/usage/meetings/2009/10/seoul/2009-09-13.meeting-packet.pdf

Follow-up on Accessibility

    Tom: Decision was posted - Liddy has posted replies on a number
    of DCMI lists.

    There was an interesting and productive meeting at DC2009 with
    Tom, Liddy, and Makx discussing the Accessibility proposal with
    Eric Miller and David Wood, who both found the proposal
    interesting.  They did not disagree with the decision to reject
    but thought it could be useful to have a DC property for

    They expressed interested in seeing a test implementation of the
    idea showing what one could do with an accessibility property -
    leaving open the question of the property name and the need for
    some wordsmithing.

    Pete: I agree that implementation would be good.  Was almost
    thinking we should require this for any term proposals -- but
    that's a separate discussion.

    Tom: Create a reference document with footnotes citing prior and
    related work.  Tom would like to see the proposal go to the
    mailing lists and see what support is shown by the Community.

    Question for UB is whether we would consider a new proposal for
    an 'accessibility' property.

    Andrew: My concern - how does UB consider new term proposals.
    Should we be adding new terms at all?  I am not saying we should
    rule this out.  Spoke with someone this morning who said our
    process is not clear enough.  Proposals result in rejection, so
    communities lose interest.

    Makx: A few issues for discussion, e.g., in Oversight Committee.
    What do we want in terms of proposals - a profile?  a profile
    with terms?  People have the impression that the UB is very
    careful.  The current approach seems to say: "No, unless" and
    "We need to be convinced".  The MARBI approach has been: "Yes,
    unless" and "Only if we think it is really wrong".  People also
    think that of APs because SWAP was rejected.  People see the
    final verdict.  Who would make the effort if they are not sure
    they have a chance?  Apart from question of what we want to
    review, there is the question of the maintenance effort we take
    on.  Makx suggests a more positive approach.

    Pete: SWAP was not the only AP considered.  The Collections AP
    was approved.  As for new terms - is this about UB/DCMI
    "endorsement"? If I were doing it now I'd find my own URI
    space, publish term, and just get on with it.

    Pete: [DCMI Metadata Terms] is not a functional set of terms -
    just a set of terms.  Question: what is the set of terms and
    what is the purpose of managing them as a set?

    Joe: Thought when I joined that the UB would be dealing with
    APs, but we're still dealing with legacy issues.  Need to
    prioritise and decide what our business is.

    Pete: My two "or" aspects above were: persistence and
    disclosure/discoverability (as well as endorsement).

    Stephanie: Evaluate APs.  The problem with terms is that some
    are too granular (i.e., they are not cross-domain).  New term
    proposals have to fit the bigger picture.

    Akira: The UB standard is a bit too high - there needs to be an
    easier way for new terms to be established.  The UB should be
    focussing on APs.  Question: what is DCMI terms and what are new
    terms in APs?

    Pete: It is easy to establish a new term - publish them in your
    own URI space.  Question: what is UB process adding to that?  UB
    commitment to reviewing and approval leads to publication on
    DCMI website, thus the visibility of terms is enhanced.  What
    requirements are being satisfied by having terms approved by the
    UB?  Various aspects to the answer.

    Makx: New term proposals are not problems but opportunities.  If
    a term isn't violating any principles then we should have it.
    Pete seemed to be saying we don't want people to do this.  The
    UB is in danger of becoming useless to those in communities if
    we don't accept new terms.  Most of what is in the term set is
    useful for people.  Acessibility is one new term that could be
    very useful and has a value to DCMI.

    Pete: Not starting from the position that UB should say no -
    trying to sort out what requirements the UB is meeting.

    Tom: For APs, maybe bar is set too high re: persistence of
    URIs.  Time to change this position and lower the bar re URI

    Tom: "is it useful" as a criterion for evaluation.  Eg
    Accessibility - if the Community is to find this useful then
    taking usefulness as a criterion is one way to proceed.
    Generally not in favour of UB considering new term proposals.
    But if we were to get a new proposal with an implementation,
    with community support, then would consider it favourably.

    Makx: I volunteer to write a short note about an alternative
    approach.  Our position should be "Yes, unless its stupid"
    rather than "no unless its useful".  Will prepare in next 3-4
    weeks and submit to UB for discussion.

    ACTION 2009-10-16: Makx to propose new UB approach to evaluating

    Tom: Difference between accepting something for review, and
    accepting something.  Resource concerns for UB.

    Julie: Need to be conscious of size of proposal and amount of
    work involved.  Not useful for the group to spend hours and
    hours on one proposal.

    Raju: Most of discussion is about legacy issues.

    Julie: I'd also add that we need to be clear about how the 
    proposal should be formatted and what is required from proposers.

    Raju: Now we have a choice about whether new terms or APs.  Need
    to be clear about whether a proposal should be an AP or a
    proposal for a new term.

    Joe: If we are going to follow the lead proposed by Makx we need
    to be very clear about what we think the review criteria are -
    what is stupid...and what is not.

    Julie: As part of review process for APs we review if new terms 
    are added or not. Part of the process could be whether the proposers 
    want the new term to be in DCMI namespace or not.

    Tom: Let's wind this up - Makx has an action to make a proposal to UB.

Administrative Components (Andrew)

Agenda says:
    -- www.bs.dk/standards/AdministrativeComponents.htm

    --  Task: Prepare a short review of ACore for discussion
        in Seoul.  What can or should the Usage Board say about
        ACore?  The review should discuss the possibility of
        defining ACore as an application profile.

    Andrew presents:

    Andrew: Original A-Core, Iannella and Campbell, 1999.
    Metadata set about metadata records.  Very simple; no large
    aims.  Only 8 properties and 4 categories.

    Hansen and Andressen added a "source" property, 2003.  Added a
    requirement that this metadata set be exchanged, so added
    interoperability.  They had a total of 23 categories - metadata
    for entire record, change, and exchange.  About the metedata:
    identifier, source, scope, comment, location, language, rights,
    dateRange, handling.  About change and update activity - action,
    name, email, contact, date, affiliation.  About transmission and
    interchange: database, transmitter, fileName, technicalFormat,
    characterSet, bibliographic formation, resultFile.

    Andrew: Have the feeling there are unnecessary properties - it
    is too complex.  For example, could drop

    Makx: Who is the 'we' that would do anything about this?

    Andrew: Don't know.

    Tom: Question is - what (if anything) should the Usage Board say
    about A-Core?  This is because there appear to be people who are
    interested in this.

    Makx: There is a proposal before the AB to look at Meta Metadata.
    They could look at the A-Core work Andrew has done.

    Andrew: If we talk to people about using this we should drop
    transmission, and there's an ISO 19115 standard adopted by AGLS,
    and maybe we don't do anything but point them to ISO.

    Tom: I have more fundamental questions.  I think this is an
    application profile, where the properties are not specified, and
    it's not clear what the domain model is.  And this would clarify
    a lot.  The URIs are under purl.org/identifier.  It looks like
    an early rough draft of an AP.  The purl doesn't work.

    Makx: This is just what Michael Panzer is proposing.  MP wants
    to add a domain model and proper AP.

    Pete: I agree with Tom.  Andy and I both made comments on this on
    the AB list back in 2003 but they were ignored.

    Tom: I propose an action for Andrew to write a brief summary of
    his work.  Action on Andrew to write brief summary of A-Core,
    and relate it to early work by Debbie and colleague, and make
    few comments on the specific properties made in the ppt?  Then
    we can send an email message giving the context, saying that we
    had a brief discussion in the UB.

    Makx: I would do it other way around.  when we discuss it
    tomorrow.  If we agree that we're setting up a Task Force, that
    we tell them they need to use Andrew's work.

    ACTION 2009-10-16: Andrew to send material to Panzer if the AB
    approves the new Task Force on Meta Metadata.

Errata and other changes to DCMI terms documentation (Akira)

Agenda says:
        This document includes some proposals to be decided formally 
        at the meeting (and documents some decisions already and in 
        the queue for publication).  After the Seoul meeting, this will
        be turned into a single decision document.

        The meeting notes for Berlin record the discussion of the literal
        range for Title and Alternative title.

    --  Task: Carefully check all of the proposed changes.
        Write a very short summary of the rationale for assigning
        a literal range to Title and Alternative title (using the 
        meeting notes above.

    Pete's proposal to delete sentences from usage comments for dcterms:contributor,
    dcterms:creator, and dcterms:publisher (see meeting packet p. 12)

        RESOLVED - To delete the sentences from the usage comments as
        per pp.12-13 of the meeting packet.

        ACTION 2009-10-16: Tom make changes in DCMI Metadata Terms
        declarations as per proposal.

        ACTION 2009-10-16: Tom to publish the text in pp.12-13 of
        meeting packet as decision text.

    Range for dcterms:title - this is approved but a note is needed
    Akira proposes the following rationale:

        Note: In October 2009, DCMI specified the range as literal,
        though there are some important uses with non-literal values of
        "title".  Main reasons are 1) Most applications use "title"
        with literal values, 2) Literal range makes implementation
        greatly simple.  Those who want non-literal values can use
        legacy http://purl.org/dc/elements/1.1/title.

    ACTION 2009-10-16: Tom to wordsmith text, add to decision
    document for DCMI Metadata Terms.

    ACTION 2009-10-16: Tom to add range "Literal" to dcterms:title in
    DCMI Metadata Terms.

    Re: 2009-04-21 - maintanance correction (see meeting packet)
        ACTION: Tom to change reference 15836-21003 to 15836:2009

    Re: 2009-05-12 - documentation error (see meeting packet).
        This action has been completed.

    Re: 2009-05-19 question: should we extend the dcmi-terms page index?
        ACTION 2009-10-16: Pete to look at XSLT for dcmi-terms page index.

    Re: 2009-08-24 issue (see meeting packet)
        ACTION 2009-10-16: Tom to correct URI

    Re: 2008-10-15 issue (see meeting packet) - no action required.

    Re: 2008-09-21 issue (see meeting packet)
        ACTION 2009-10-16: Tom to correct RDF schemas

    Re: 2009-07-23 - RDF schema proposed by Pete
        Usage Board: APPROVED
        ACTION 2009-10-16: Tom to add see also link to http://purl.org/dc/dcmitype/ (with final slash!)

    Re: 2009-07-23 - Guidelines for Dublin Core Application Profiles (see meeting packet)
        ACTION 2009-10-16: Tom to make correction regarding ISO639-2 as proposed
        ACTION 2009-10-16: Tom to add resource class constraint
        For both actions, Tom should first consult co-author Karen Coyle.

Usage issues (Pete)

Agenda says:
--  Creator and Maker

--  Candidate issues for further discussion
        "Using Dublin Core Part 6: Using Agent Roles"

    Simple Dublin Core
        -- www.intute.ac.uk/publications/eprints-uk/simpledc-guidelines.html

    --  Task: Follow dc-architecture discussion regarding
        DC creator and FOAF maker and summarize discussion to
        dc-usage by Friday, 2 October.  Prepare bullet points
        for discussing other issues (see above) in order to
        identify topics for further discussion in the Usage
        Board.  Propose a one-paragraph glossary entry for
        "Simple Dublin Core" for discussion.  Could Agent Roles
        be discussed in a short glossary entry?

    Pete: usage issues that need to discussed:
    1. Relationship between foaf:maker and dcterms: creator
    2. Issues around dc:identifier and dcterms:identifier
    3. Usage document
    4. Agent roles

    Agent roles won't be discussed here.
    1. Relationship between foaf:maker and dcterms:creator
       Slides sent previously
       Using dc:creator - historical ambiguity in using this term: 
       inconsistent semantics in DC documents. So could be used with both 
       literal and non-literal values.
       Led to data processing difficulties. To remedy this 'messiness', 
       FOAF community coined its own property foaf:maker.
       Also asserted that foaf:maker could be used with dc:creator 
       provided dc:creator only used literals.
       Now the situation is that foaf:maker says exactly the same thing 
       as dcterms:creator but this is not stated formally.
        FOAF says
            foaf:maker rdfs:subPropertyOf dcterms:creator .
        DCMI says
            dcterms:creator rdfs:subPropertyOf foaf:maker .

    Andrew: why isn't it a problem that two things are sub-properties of each other?
    Pete: It's a relationship statement in RDFS and both triples can be inferred - 
    from either statement both triples are able to be inferred. RDFS says this is OK.

    FOAF to drop guideline re use of dc:creator with literal values (suggested by TomB).

    At a technical level mutually sub-property assertions are not a probelm. 
    It enhances interoperability.
    Not necessary technically to publish changes together but maybe good politically.
    Few comments when posted to DC Architecture.

    Pete: Andy Powell said we haven't made any such assertions before so this would 
    set a precedent - should we do it and would that mean we could be asked to make 
    more such assertions?

    Andrew: Could it matter if we made more assertions of this type?
    Pete: Might be useful to formally assert a number of other relationships.
    Pete: We could either agree to make the assertion or go back to DanB.
    Akira: Why isn't it just a synonym?
    Pete: It could be but you can't say that in RDFS.
    Pete: The sub-property assertion is almost the same as saying 
    they are synonyms. It might be possible to do it in OWL.
    This might be a stronger approach

    Tom: propose that UB take the initiative and formulate (if we 
    agree) a proposal to the send to the list for comments from the 
    OWL community.

    Tom: would set an important precedent and is an important social
    question with multiple vocabularies - no one is doing anything
    about this so it would be good for DCMI to be proactive.
    We could articulate clearly that this is an experiment and we 
    want to stimulate discussion about what's the best way to achieve 
    this (i.e., with mutual assertions).  We should get reaction from 
    OWL and RDF communities about whether these type of declarations 
    are the right way to go.

    Joe: Yes, this should be done but we need to think about the criteria 
    and state principles about why we are doing this now.
    Tom: Will work with Pete on this.

    ACTION 2009-10-16 Pete and Tom: Pete will investigate OWL
    further to see whether it is possible to do this using OWL;
    Pete and Tom will work up a post to email to the DC
    Architecture and the Semantic Web community with cross
    postings pointing to the DC Architecture list email.

    Pete: I think the OWL construct to look at is

    Pete: OWL property equivalentProperty may be the appropriate one.
    Tom: question for the semantic web community.

2. Simple DC

    Pete: The idea of simple DC is mentioned in a number of documents.
    We can think of simple DC as a description set profile OR as a DC 
    application profile.  I have no preference for the approach as long
    as we are consistent.  The core question is: which of the two DSP 
    "patters" do we want to use?

    Tom: suggest we defer issue of 'dumb down'.  Suggest we do both 
    legacy and modern - better than having either one alone.

    Pete: agrees with this suggestion.
    Stephanie: First question - should it be a DSP or a DCAP?
    Pete: Thinks DSP is the best way to go
    Tom: Functional requirements were deliberately underspecified at the 
    beginning.  This allowed DC to get going.  Shouldn't try to retrofit
    functional requirements that would be necessary for an AP.
    Julie agrees.
    Tom: Suggest we keep on UB agenda but not with highest priority.
    Stephanie: Problem with not having a high priority - should have a 
    high priority because it is needed for implementors now.
    Tom: how about medium-term priority - agreement that we should have both 
    the proposed DSP.

    ACTION 2009-10-16: Pete and Tom to write up explanation using two simple DSPs.

3. Use of dcterms: identifier

    URI as a literal value
    Tom: need to bookmark this when we look at FAQ and glossary
    ACTION 2009-10-16: Tom and Pete to capture essence of the issues in a short 
    paragraph to take to DC Architecture.

    Joe: Identity and location is an old issue (ie. raised some some time ago).
    Not a big deal but seems to have connections with discussions about what a subject is.
    We need to be explicit about our philosophy.

Glossary (Joe)

Agenda says:
        "Using Dublin Core - Part 7: DCMI Glossary" 
        Tom proposes that the glossary be written as a relatively short
        document covering only major concepts that are characteristic of
        Dublin Core metadata.  The glossary is potentially a good place to
        explain legacy issues, such as "dumb down" and "document-like object".
    Candidate issues for inclusion (or summary) in a glossary:

    --  Task: Identify which of the terms in the old glossary
        are most important for describing the "Dublin Core style"
        of metadata.  For those most important terms, suggest bullet
        points for what a modern glossary entry should say.  Flag any
        obvious gaps -- DC terminology that would need to be covered
        in a glossary, such as the "candidate issues" above (and suggest
        bullet points).

    Tom: Issues that could be covered in a glossary include pre-DCAM vs post-DCAM, 
    prescriptive vs. descriptive.  Two different functions of glossary: the past 
    and what is now.  Should be a small document.  

    Joe: Suggest two glossaries.  One post-DCAM glossary and one for
    the legacy stuff which is pre-DCAM, with cross-references
    between the two.  The InterPARES Project [1] did this with
    digital archives.

    [1] http://www.interpares.org/

    General point: one prescriptive and one descriptive glossary.
    One will be a dictionary - that will be pre- and post-dcam.
    90% of the old glossary will not go in the new one.

    ACTION 2009-10-16: Tom to carry the glossary forward.

Frequently Asked Questions (Julie)
--  Legacy FAQ
--  DCMI Mixing and Matching FAQ (Andy Powell, 2005)
--  Candidate FAQ

    --  Task: Identify which questions are still really
        frequently asked.  For those questions, prepare bullet points
        proposing current answers.  Propose an answer to the
        frequently asked question about the difference between
        dc:creator and dcterms:creator.


    Tom: See document Julie send some hours ago [*].  We should also
    consider the new Web pages.  The role of the FAQ is to show the
    DC-specific jargon like dumb-down principle, qualifiers etc.
    For example, what is the difference between dcmes and dcmi

    [*] http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-16.FAQ-julie.doc

    Julie: Number 1 is not used any longer
    Yes -  1. What is metadata?
    The simplest definition of metadata is " structured data about data."
    Metadata is descriptive information about a resource whether it be physical or 
    electronic. The underlying concepts behind metadata have been in use for as 
    long as collections of information have been organized. Library card catalogs 
    represent a well-established example of metadata for resource discovery.
    Metadata can be generated either "by hand" or derived automatically using 

    Julie: Numbers 2 to 5 not really used any longer.
    No -  2.  Where is the metadata on the Dublin Core website? [does 
    anybody actually ask this?]
    No -  3.  What is a resource?
    No -  4.  What is resource discovery? 
    No - 5.  What is the Dublin Core Metadata Initiative? [this is on the 
    homepage, who on earth would miss that!]

    Julie: Number 6 for the glossary and used for the introduction of using dc
    Yes - 6. What is the Dublin Core?
    The Dublin Core Metadata Initiative develops and maintains specifications in 
    support of resource description. These include the DCMI Metadata Terms, 
    which includes the classic Dublin Core Metadata Element Set, the DCMI Type 
    Vocabulary, and resource classes used as formal domains and ranges, along 
    with supporting documents, usage guides, the Dublin Core Abstract Model and 
    other model-related specifications, and a set of syntax guidelines for encoding 
    Dublin Core in HTML, XML and RDF.
    Further information: http://dublincore.org/documents/

    Julie: Number 7 dc simple and qualified should be part of the glossary (old)
    No -  7.  What is the Dublin Core Metadata Element Set? 

    Julie: Numbers 8-10 not used any more.
    Julie: Number 8 answer has to be: why use dc in various meanings = multiple questions
    Change - to "Why use Dublin Core?" 8.  Who can benefit from
    using the Dublin Core Metadata Element Set?  Dublin Core offers
    a means of describing resources in a standard way.  It is
    particularly useful where interoperability with other systems is

    Change - to 'What is Simple Dublin Core?' 
    9.  What is the difference between "Simple" ("unqualified") and "Qualified" Dublin Core? 
    "Simple" Dublin Core refers to the Dublin Core Metadata Element Set Version 
    1.1, a set of 15 metadata properties for describing resources.
    Further information: http://dublincore.org/documents/dcmi-terms/

    Add - "What is 'Qualified' Dublin Core?"

    The phrase "Qualified" Dublin Core is a legacy term often used to refer to the 
    extended set of properties now maintained by Dublin Core. 

    Add - what are Dublin Core Application Profiles?

    In current practice, Dublin Core is more focussed on the development of 
    "application profiles" than on registering new metadata properties. A Dublin 
    Core Application Profile defines metadata records which meet specific 
    application needs while providing semantic interoperability with other 
    applications on the basis of globally defined vocabularies and models.
    Further information: http://dublincore.org/documents/profile-guidelines/

    No -   10.  Should I use Simple or Qualified Dublin Core? 
    No -  11.  How do I begin implementing the Dublin Core Metadata Element Set?

    Yes - 12.  What is the relationship between the DCMI and other Internet 
    standards groups? [keep text if this is this still correct?]

    No -  13.  Was the Dublin Core intended to be used only for digital or 
    Web-based resources? 
    No - 14.  How is Dublin Core metadata used? 

    Julie: Number 15 will stay
    Yes - 15.  How is Dublin Core metadata stored? 
    Dublin Core can be stored as part of the HTML header of a web resource, as an 
    XML or RDF document, or can be mapped into a database structure.

    Change to - "Can I embed Dublin Core metadata within my HTML 
    documents?" 16.  How can I embed Dublin Core metadata within my HTML documents? 
    Yes. See http://dublincore.org/documents/dc-html/

    No - 17.  What is the relationship between Dublin Core Metadata and RDF and XML? 

    Change - to "What is the Dublin Core Abstract Model" 18.  What is the 
    Dublin Core data model? 
    The Dublin Core Abstract Model (DCAM) specifies the components and 
    constructs used in Dublin Core metadata. It defines the nature of the 
    components used and describes how those components are combined to create 
    information structures. It provides an information model which is independent 
    of any particular encoding syntax. 
    Further information: http://dublincore.org/documents/abstract-model/

    No - 19.  How do I participate in discussions about the Dublin Core? 
    No - 20.  What is the maximum length for each field in Dublin Core? 
    No - 21.  What is an attribute-value pair? 
    No - 22.  What is the Warwick Framework? 
    No - 23.  What search-engines support the Dublin Core? 

    Julie: Number 24 maybe stay.
    24.  Can I add a new element to Dublin Core? [a. yes, but you don't 
    necessarily have to, just declare it]

    New properties can be formally considered by the Dublin Core Usage Board, 
    although creators of  Dublin Core Application Profiles are free to define and 
    declare their own metadata properties, or to use properties from existing 

    Section 2.5 of the following document specifies what constitutes a "valid"
    metadata property: http://dublincore.org/documents/profile-review-criteria/

    No -  25.  What is the Open Metadata Registry? 
    No - 26.  How do I store proper names in Dublin Core? 
    ? - 27.  DCMI Intellectual Property FAQ 

    Yes -  28.  What is the "Dumb-Down" Principle? 
    [This needs discussion]

    Julie: Possible candidates for staying are 29 and 30.
    Change - to "Can I add a new property to Dublin Core Metadata Terms?"
    Change - to "Can I use controlled vocabularies for different metadata 
    properties?" - 29.  How can I use existing controlled vocabularies for DC 
    Subject metadata? 
    Yes. DCMI registers a number of vocabularies in DCMI Metadata Terms: 

    Change - to "Can I use vocabularies that are not approved by DCMI?" -
    30.  Can I use controlled vocabularies that are not approved by DCMI? 
    Yes. DCMI has registered registers a number of vocabularies but does not aim 
    to register all possible vocabularies. There are, of course, many others that are 
    equally legitimate, and it has always been our intent that communities of 
    expertise be able to leverage the value of such existing schemes in their 
    metadata. To promote interoperability, it is recommended that application 
    designers review registered controlled vocabularies for one that may be 
    suitable for their application.

    Yes -  31.  What are the DCMI Namespaces?
    Text as is
    Add - "What is the difference between dcterms:creator and dc:creator?"
    [I don't know what the answer is]

    Add - difference between literal and non-literal.  Between VES and SES.


    Julie: Separate the questions by what, how etc.
    What questions really belong in the FAQ?

    Pete Johnston: I'm just comparing with http://www.w3.org/2001/sw/SW-FAQ which 
    doesn't really have many "whwt is X?" questions

    Thomas Baker: Usage notes instead of FAQ?

Using Dublin Core - Elements and Qualifiers (Stefanie)

    We considered:
    -- http://dublincore.org/documents/usageguide/elements.shtml
       "Using Dublin Core Part 4: The Elements"
    -- http://dublincore.org/documents/usageguide/qualifiers.shtml
       "Using Dublin Core Part 5: The Qualifiers"
    -- http://dublincore.org/usage/meetings/2009/10/seoul/.html/usingdc.html
       Comments by Pete on "Using Dublin Core"

        "In Seoul, we will not have time to discuss all of the
        examples for elements and qualifiers in Using Dublin
        Core.  Rather, the task here is to prepare bullet points
        on general issues related to the examples, for example
        the issue of literal versus non-literal values.  Prepare
        to discuss possible ways forward for Using Dublin Core:
        what would need to be done in order to bring the
        document up to date?  Is a document at this level
        needed, and what is its audience?"

    Stephanie: Looking at Using Dublin Core chapters 1-3.  Cannot
    work just on elements without knowing what's going to be on the
    Introduction.  The document needs a new introduction, saying
    what DC is and the principles and goals of DCMI. Historical view
    of how we got the elements and terms.  Localisation groups need
    something simple for new implementers.  Chapter 2: technical 
    issues, XML, RDF etc -- should be really short.

    Pete: Maybe syntax should come at the end.  DC is now seen as a set
    of "properties" so not useful to talk about "elements".

    Tom: A question: How helpful generally are the notes/guidelines for 
    the creation of content (included in many of the term descriptions)
    in the current User Guide?

    Stephanie: Useful but all examples are very bibliographically
    focussed -- i.e., they deal with library materials almost
    exclusively.  Users need to be told that properties apply, in
    principle, to any resource, not just bibliographical.

    Tom: Can we take all the usage notes and put them in a wiki and let 
    people have a go at them for a while. Would that work?

    Pete: FWIW, I think the FOAF document has a nice style of
    guideline.  But it is a bit variable.  Some properties have
    detailed guidance, others almost none.
    See e.g. http://xmlns.com/foaf/spec/#term_currentProject

    Tom: Examples to cover some of the more interesting cases rather
    than everything in the guide.

    ACTION 2009-10-16: Stephanie to write an Introduction for new
    Guidelines, using Diane's contents list as the basis.

    ACTION 2009-10-16: Stephanie to find examples for the
    interesting (i.e.  difficult) properties to clearly show their