Usage Board Barcelona 

Date: Friday-Saturday, 16-17 March 2007

Agenda:          http://stage.dublincore.org/usage/meetings/2007/03/barcelona/html/index.html
Meeting packets: http://dublincore.org/usage/meetings/2007/03/barcelona/2007-03-16.ub-agenda-barcelona.pdf
                 http://dublincore.org/usage/meetings/2007/03/barcelona/2007-03-17.barcelona-cdap.pdf

In attendance: 
-- Usage Board: Diane Hillmann, Stuart Sutton, Makx Dekkers (ex officio), 
                Akira Miyazawa, Andy Powell, Joe Tennis, Tom Baker (chair) 
-- Guests:      Pete Johnston (Friday only), Raju Buddharaju, Jon Phipps (via Skype)

----------------------------------------------------------------------
1. Outstanding Actions (Tom) 

   [CONTINUES] ACTION 2006-10-01: Tom to replace the Principles
   document at http://dublincore.org/usage/documents/principles/
   with a page that copies the definitions of elements etc from
   DCAM and includes a short text stating: that the document which
   used to live here has been superseded by the DCAM. Update UB
   page to say we do things in light of the DCAM.
   
   [CONTINUES] ACTION 2006-10-01: Tom to look through DCMI site
   and note those pages where a reference to the principles
   document needs to be changed to a reference to the DCAM
   as appropriate.

----------------------------------------------------------------------
2. Domains and Ranges (Andy) 

   Note: In the following section, wherever we say "resource" we mean 
   non-literal resource.  See section on Problematic Properties. 

   Note: In Barcelona, the terms were taken out of order, starting
   with "audience".  In these revised notes, the terms have been put
   back into their usual order.

-- DC-15 properties from /1.1/ namespace now declared also in /terms/

    contributor: 
    AGREED: approved 

    coverage: 
    AGREED:approved 

    LocationPeriodJurisdiction: 
    AGREED: approve 

    Jurisdiction: 
    AGREED: approved 

    creator: 
    AGREED: approved 

    date: 
    AGREED: domain is approved, propose range as literal (go to comment with 
    this) 

    description: 
    AGREED: domain of non-literal resource and range of rdfs:resource 

    format: 
    AGREED: approved 

    identifier: 
    AGREED: approved 

    Reference: 
    AGREED: approved 

    language: 
    AGREED: the defintion of language should include computer languages, sign 
    languages, and written languages 
    ACTION: define language (Diane Hillmann) 
    SUGGESTION: system for communicating ideas and feelings using sounds, 
    signs, gestures, and marks 
    SUGGESTION: add a comment to say that it includes written, spoken, sign, 
    and computer languages 

    Language: 
    AGREED: see language above 

    publisher: 
    AGREED: approved 

    relation: 
    AGREED: approved 

    rights: 
    AGREED: approved 

    RightsStatement: 
    AGREED: change definition to: 
    A statement about the intellectual property rights (IPR) held in or over a 
    Resource, a legal document giving official permission to do something with 
    a resource, or a statement about access rights. 

    source: 
    AGREED: approved 

    subject: 
    AGREED: approved 

    title: 
    AGREED: domain is approved, range propose literal, and then send out for 
    discussion 

    type: 
    AGREED: approved 

-- Terms which have always been in the /terms/ namespace

    abstract: 
    AGREED: domain non-literal and range is rdfs:resource 

    accessRights: 
    AGREED:approved 

    accrualMethod: 
    AGREED: approved 

        AccrualMethod: 
        AGREED: approved 

    accrualPeriodicity: 
    AGREED: approved 

        Frequency: 
        AGREED: approved 

    accrualPolicy: 
    AGREED: approved 

        Policy: 
        AGREED: approved 

    alternative - 
    AGREED: domain is resource, range rdfs:resource 
    AGREED: go to comment because this is problematic property [see 
    Problematic Property section below] 

    audience - 
    AGREED: accept the domain of resource and range of AgentClass 

        AgentClass -- 
        AGREED: approve the term with a change the definition of AgentClass to "a 
        group of Agents" 

    available -- 
    AGREED: domain is resource, we don`t know what to have as range 

    bibliographicCitation -- 
    AGREED: approved 

        BibliographicResource -- 
        AGREED: approve with change to definition, changing "published resource" 
        to "documentary resource" 

    BibliographicReference -- 
    AGREED: approved 

    conformsTo -- 
    AGREED: approved 

        Standard 
        AGREED: approved 

    created 
    refer to available 

    dateAccepted 
    refer to available 

    dateCopyrighted 
    refer to available 

    dateSubmitted 
    refer to available 

    educationLevel 
    AGREED: approved 

    extent 
    AGREED: approved 

    hasFormat 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    hasPart 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    hasVersion 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    instructionalMethod 
    AGREED: approved 

    isFormatOf 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    IsPartOf -- isReferencedBy -- isREplacedBy -- isRequiredBy -- isVersionOf 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    issued 
    AGREED: domain is ok, querying the range 

    license 
    AGREED: approved 

    mediator 
    AGREED: approved 

    medium 
    AGREED: approved 

    modified 
    AGREED: domain is ok, propose range as literal (go to comment with this) 

    provenance 
    AGREED: approved 

    references 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    replaces 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    requires 
    AGREED: non-literal resources is both the domain and range so left 
    unspecified until Singapore 

    rightsHolder 
    AGREED: approved 

    spatial 
    AGREED: approved 

    Location: 
    AGREED: approved 
    AGREED: change definition to "a named place or spatial region" 

    tableOfContents: 
    AGREED: rdfs:resource as range 
    AGREED: not a case where we mean non-literal resource (because 
    description allows images) 

    [may not have captured all approved 1.1 above, e.g., I did capture 
    Location] 

    temporal 
    AGREED: with change in the definition Period 

    Period 
    AGREED: change definition to "interval of time that is named or defined by 
    its start and end dates" 
    AGREED: this is broader than the range of date and its subproperties and 
    should be noted 

    valid 
    AGREED: domain is ok, propose range as literal (go to comment with this) 

-- Problematic properties 

   ISSUE: A title with multiple encodings is different from
   multiple title statements.

   ISSUE: When domain is stated to be rdfs:resource in /terms/
   part of the Domains proposal we intend it to mean non-literal
   resource because the meaning of rdfs:Resource is broader
   and includes literals.

   ISSUE: Where the domain and range is resource, we can
   either say nothing, or we can say rdfs:Resource (which
   is stating the obvious) -- this is related to our actions
   related to specifically stating non-literal resource.

   ISSUE: Because we have inverses in the isFormatOf type
   properties, we need the same class at both ends of the
   inverse -- therefore we should make all non-literal
   resources (TBA).

   AGREED: We are going to propose that range of description,
   abstract, and table of contents is rdfs:resource  knowing
   that this causes OWL-DL incompatability for these properties
   - this will go out for comment - we're asking if this is
   reasonable to do this for these three properties.

   AGREED: We need a class and will define a class of
   non-literal resources for both domains and ranges.

   ACTION: Add a new class of non-literal resource to the wiki,
   use as domain and range as appropriate (Andy).

   AGREED: Usage of this [non-literal] class for domains
   should be part of the next comment period.

   ACTION: Investigate whether owl:Thing is a suitable thing
   for defining a class of non-literal resources (DONE).  [Tom
   later adds, from memory: We looked at the OWL spec and the 
   formal semantics seemed worryingly opaque.]

   ACTION: Transcribe easel graph into the meeting (Tom and Andy 
   have pictures) (Tom) 

   ACTION (for lack of volunteers, by default Tom): write a
   proposal capturing the issue of string, unspecified, and
   thing for the problematic DCTERMS properties (title and its
   subproperties, date and its subproperties, and description
   and its subproperties).  Taking the following position:

   1. Title and its subproperties as literals [check notes]
   2. Date and its subproperties as literals 
   3. Description and its subproperties as range = rdfs:resource

   Then send this proposal out for public comment.  There
   are two audiences for this comment: (1) multiple script
   communities and (2) SW community asking: best practice for
   unspecified ranges.  Note that we will use the non-literal
   resource in all cases where the domain of our properities
   is listed as rdfs:resource (in the proposal).



-- Undeclared legacy DCTERMS classes (SubjectScheme, etc, p.64)
   http://dublincore.org/usage/meetings/2007/03/barcelona/SubjectScheme.txt

   ACTION: Tom will write a paragraph about these placing them in 
   historical context (Tom).

-- Term type of existing encoding schemes (p.65)
   http://dublincore.org/usage/meetings/2007/03/barcelona/Encoding-schemes.txt

   AGREED: We need a deeper level of description/differentiation 
   between VES and SES, including definitions.

   If you have a something already, how do you tell if it is VES or SES.  If an ES 
   tells you what a value string it it's a SES.  If ES defines a class of values, 
   then it is a VES (e.g., concepts). 

   For example, if you develop a list of educational levels, and if you define a 
   list of strings, then you're defining an SES.  If you define a set of concepts 
   and assign URIs to them (as best practice), then you're defining a VES. 

   Best practice in this scenario is to define a set of concepts with URIs rather 
   than a set of strings. 

   ACTION (Stuart and Joe): Write a one-page explanation
   differentiating VES and SES, vet with Pete Johnston,
   and consider revisions to the Term Decision Tree:
   http://dublincore.org/architecturewiki/TermDecisionTree.
   (Note: the difference is basically String vs. Thing.)

   
   AGREED: DC-Education is a great test-bed for these concepts 

   SES is a datatype in RDF ( 
   VES is a set not in RDF (effectively the same as conceptScheme in SKOS, 
   except it's not limited to concepts) 
   
   DISCUSSION: 
   VES is a set of concepts that, once in metadata, allows editors to handle 
   assertion by adding things to it 
   SES is a set of strings 
   
   
   PROPOSAL: 
   change the generic "encoding scheme" in DCTERM declaration and 
   documentation to "vocabulary encoding schemes" or "syntax encoding 
   schemes" following the classification on page 66 of the meeting packet. 
   VOTE: 
   AGREE - 4 
   DISAGREE - 0 
   ABSTAIN - 2 
   VOTE ANNULLED (after 30 seconds) 
   
   AGREED: with the categorization on page 66 except in the following cases 
   (which 
   
   PROPOSAL: 
   change the generic "encoding scheme" in DCTERM declaration and 
   documentation to "vocabulary encoding schemes" or "syntax encoding 
   schemes" following the classification on page 66 of the meeting packet.  
   
   PROPOSAL: 
   we interpret these things as where SES is a set of strings and VES is a set of 
   concepts: 
   
   Vote on individual schemes: 
      http://purl.org/dc/terms/ISO3166   SES    5   VES  1   ABSTAIN 0 
      http://purl.org/dc/terms/ISO639-2     SES    5  VES 1    ABSTAIN 0 
      http://purl.org/dc/terms/RFC1766    SES   5 VES 1  ABSTAIN 0 
      http://purl.org/dc/terms/RFC3066      SES  5  VES   1  ABSTAIN  0 
   
      http://purl.org/dc/terms/IMT         SES  0  VES 5  ABSTAIN  1 

----------------------------------------------------------------------
3. DCTERMS definitions and comments (Tom) 

-- Proposal for changes to DCTERMS
   http://dublincore.org/usage/meetings/2007/03/barcelona/DCTermsChanges.pdf

    Audience = ok 

    Alternative=(has a typo)=ok 

    TableofContents=ok 

    Abstract=ok 

    Created=ok 

    Valid=ok 

    Available=ok 

    Issued=ok 

    Modified=ok 

    Extent=(need to correct comment)=ok 

    Medium=no changes 

    IsVersionOf=ok 

    HasVersion=ok with first revised definition, with adding
    "A related resource that is" at the beginning

    IsReplacedBy=ok, change which to that (and be consistent with DCTERMS - 
    ACTION: do a which hunt Tom)) 

    Replaces=ok 

    IsRequiredBy=no (change to make parallel with Requires)
    "A related resource that requires the described resource
    to support its function, delivery, or coherence"

    Requires= change to "A related resource that is required by
    the described resource to support its function, delivery,
    or coherence" drop 'content'

    IsPartOf=change to "A related resource in which the
    described resource is physically or logically included."

    HasPart= change to "A related resource that is included
    either physically or logically in the described resource."

    IsReferencedBy= change to "A related resource that
    references, cites, or otherwise points to the described
    resource."

    References=change to "A related resource that
    is referenced, cited, or otherwise pointed to by the
    described resource."

    IsFormatOf= change to "A related resource that is
    substantially the same as the described resource, but in
    another format"

    HasFormat=change to "A related resource that is
    substantially the same as the pre-existing described
    resource, but in another format."

    conformsTo: 
    AGREED: approved 

    spatial: 
    AGREED: approved 

    temporal: 
    AGREED: approved 

    mediator: 
    AGREED: definition approved, comment should be a list in this case: 

    In an educational context, a mediator might be a parent,
    teacher, teaching assistant, or care-giver

    dateAccepted: 
    AGREED: approved 
    ACTION: delete "freestanding property label" (Tom) 

    dateCopyrighted: 
    AGREED: change defintion to "Date of copyright." 
    ACTION: delete "freestanding property label" (Tom) 

    dateSubmitted: 
    AGREED: approved 
    ACTION: delete "freestanding property label" (Tom) 

    educationLevel: 
    AGREED: change the definition.  remove "audience" in the definition, and 
    replace it with "a class of entity" and remove "its", so it reads: "A class of 
    entity, defined in terms of progression through an educational or training 
    context, for whom the resource is intended." 
    JUSTIFICATION: parallel construction 

    accessRights: 
    AGREED: change comment to: "Access Rights may include information 
    regarding access or restrictions based on privacy, security or other policies." 
    - this substitutes policies for regulations 

    bibliographicCitation: 
    AGREED: approved 

    license: 
    AGREED:remove comment 
    JUSTIFICATION: we don't say anything about value URI in any other 
    comment AND it's an application profile issue as to whether or not a value 
    has a URI, therefore we don't need the Creative Commons example 

    rightsHolder: 
    AGREED: remove comment 

    provenance: 
    AGREED: approved 

    instructionalMethod: 
    AGREED: approved 

    accrualMethod: 
    AGREED:approved 

    accrualPeriodicity: 
    AGREED: approved 

    accrualPolicy: 
    AGREED: approved 

    LCSH: 
    AGREED: change definition: "The set of concepts defined by the Library of 
    Congress Subject Headings" 

    MESH, LCC, DDC, UDC 
    AGREED: change definition to start: "The set of concepts..." 

    DCMIType 
    AGREED: change to "A set of concepts used to categorize the nature or 
    genre of the resource." 
    ACTION: Tom to add a change note that there was systematic change 
    "content of the resource" 

    IMT: 
    AGREED: change definition to "Set of concepts defined by IANA used to 
    indicate the media type of the resource" 

    ISO639-2: 
    VOTE ON: change to "The set of three-letter codes listed in ISO639-2 for the 
    representation of names of languages" 
    AGREE 5 
    DISAGREE 0 
    ABSTAIN 1 

    ISSUE: we recognize a set of concepts for language, however, interpreting 
    the ISO639-2 as a set of concepts would break the namespace policy 
    because ISO639-2 is a set of strings (defined by ISO and us). 

    ACTION: Joe will draft a document discussing issues related to principles 
    and purpose of UB decision-making 

    RFC1766: 
    AGREED: change to "The set of tags, constructed according to RFC 1766, for 
    the identification of languages" 

    URI: 
    AGREED:change to "The set of identifiers constructed according to the 
    generic syntax for Uniform Resource Identifiers, as defined by the IETF" 

    ISSUE: because of the way RFCs work, they change and take on a different 
    number 

    Point: 
    AGREED: change to "the set of points in space defined by their geographic 
    coordinates according to the  DCMI Point Encoding Scheme" 

    ISO3166: 
    AGREED: change to "The set of codes listed in ISO 3166-1 for the 
    representation of names of countries" 

    Box: 
    AGREED: change to "the set of regions in space defined by their geographic 
    coordinates according to the  DCMI Box Encoding Scheme" 

    TGN: 
    AGREED: change to "the set of places defined by the Getty Thesaurus of 
    Geographic Names" 

    Period: 
    AGREED: change to "the set of time intervals defined by their limits 
    according to the  DCMI Period Encoding Scheme" 

    W3CDTF: 
    AGREED: change to "set of dates and times constructed according to the 
    W3C Date and Time Formats Specification" 

    RFC3066: 
    AGREED: change to "The set of tags, constructed according to RFC 3066, for 
    the identification of languages" 
    AGREED: add comment "RFC 3066 has be obsoleted by RFC 4646" 

    NEW TERM 
    RFC4646 
    AGREED: add definition "The set of tags, constructed according to RFC 
    4646, for the identification of languages" 

    NLM: 
    AGREED: change to "The set of concepts defined by the National Library of 
    Medicine Classification" 

    ACTION: Tom change all encoding schemes to follow the LCSH change in 
    definition 
    ACTION: Tom to find "uses a controlled vocabulary", report to list, and 
    remove from comments.  

    NOTE: if interoperability is operationalized as keeping current encoding 
    schemes already in our namespace, then we should add new terms to keep 
    it up to date. 

    QUESTION: Do we need "qualifies statements"? [e.g., p. 57] 
    AGREED: remove "qualifies" statements and discuss encoding schemes in 
    application profiles only, not in dcterms 
    JUSTIFICATION: this kind of information belongs in an application profile 

    QUESTION: do we want to now formally declare subproperty relationships 
    for contributor, subject, and relation? 
    AGREED: yes for contributor and relation; no for subject [p. 41] 
    JUSTIFICATION: for contributor and relation = clarifies semantics 

----------------------------------------------------------------------
4. DCMES finalization (Akira) 

-- Topic page
   http://dublincore.org/usage/meetings/2007/03/barcelona/Topic-nisoballot.txt

-- Summary of NISO ballot comments
   http://dublincore.org/usage/meetings/2007/03/barcelona/Z39-85_Ballot_comment_responses.pdf

    Task: respond to NISO based on comments, then put any editorial changes 
    out for DCMI public comment 
    ACTION: Akira and Tom to draft text in accordance with those changes 

    Comment 2 p. 67-68: 
    AGREED: adopt changes proposed 
    NOTE: check the Abstract Model 

    Comment 3 p. 68 
    AGREED: adopt changes proposed 

    Comment 4 p. 69 
    AGREED: comment starts: "spatial topic and spatial applicability may be..." 

    Comment 5 p. 71 
    AGREED: we will leave things as they are because it is not part of the 
    definition 
    JUSTIFICATION: the comment of 2001 was not intended to mean that 
    format should be used to record information about hardware and software, 
    rather the intent was that software could take decisions based on 
    infomration recorded in Format - for example the use of 
    Application/MS-Word as a value for Format can be used by software to 
    determine that Office is required to read the file, however, we recognized 
    that the sentence was abiguous and therefore decided to remove it, further 
    no negative feedback from DCMI Community.  we've always seen 
    dimension as falling within the semantics of the format property. 

    Comment 6 p. 72 
    AGREED: adopt changes 

    Comment 7 p. 73 
    AGREED: change definition: "A related resource from which the described 
    resource is derived" 
    AGREED: leave the comment unchanged 

    Comment 8 p. 73-74 
    AGREED: adopt changes 

    Comment 9 p. 74 
    AGREED: we recognize this is confusing, and propose to remove the 
    comment completely 

    Comment 10 p. 77 
    AGREED: the comment as we had it was potentially misleading because 
    people might assume that "general category" is a subject category, which 
    was not intended 
    ACTION: Tom check 2004-2005 change 

    Comment 1 p. 67 
    AGREED: DCMES defines a set of terms.  It does not define and application 
    in which those terms are used. 
    See http://www.niso.org/standards/resources/DC-NLM-vote.html 

----------------------------------------------------------------------
5. Review of application profiles 

-- Review guidelines (Stuart)
   http://dublincore.org/usage/meetings/2007/03/barcelona/ProfileReviewCriteria.pdf

   AGREED: The following are the three categories used to
   evaluate application profiles that come before the UB:

   1. Conforms to the DCMI Abstract Model (done - see Manzanillo notes) 
   2. Internal consistency 
   3. Documented according to our guidelines for application profiles 

----------------------------------------------------------------------
-- Collection Description Application Profile (Joe)

   -- Topic page
      http://dublincore.org/usage/meetings/2007/03/barcelona/Topic-cdap.txt
   -- Revised CDAP
      see separate meeting packet 2007-03-17.barcelona-cdap.pdf
   -- Usage Board feedback, December 2006
      http://dublincore.org/usage/meetings/2007/03/barcelona/CdapFeedback.pdf
   -- Table showing response to feedback
      http://dublincore.org/usage/meetings/2007/03/barcelona/ComparisonRubric.pdf
   -- Usage Board review - draft
      http://dublincore.org/usage/meetings/2007/03/barcelona/CdapReview.pdf

    New version received Saturday night, not much time to review. 

    Issue 1: data model, its role in the AP.  They have
    removed references to the AMCC that require dependency,
    still a relationship.
    p. 154 contains a reference, describes the relationships with the model, Joe 
    suggests clarification needed. 
    on p. 10 of the ap document, a UML-like diagram, describes their now 
    free-standing data model. A bit later there's a separate model of the layers. 
    Joe points out that there is no distinction between physical or digital 
    resources, both can have locations. Raju asks whether items (his example 
    was serials) can be spread across multiple collections, answer is ambiguous. 

    Issue 2. Document and scope, p. 88 of the packet. New
    section, purpose and scope has been added.

    Issue 3. Confusion between collections and "collections
    of collections".  Went back to one profile from two
    separate ones, and confusing bits have been clarified.

    Issue 4. Change of Label for "Collection-Description".
    Aspect of confusion problem above. Have attempted to
    identify terms better in their property list.

    Issue 5. Conflation of unitary finding aids and
    catalogs/indices Confusing use with the AP, generally
    stems from AMCC model.  Defined, but not in the
    pictures, suggests it's a leftover from the AMCC model
    dependency. Andy thinks this isn't necessarily a problem.
    Other related issues are whether they're using "record"
    and not indicating where it is defined, may be DCAM.

    Issue 6: The term "content" is used in the definition
    of item. Issues raised about location and the lack of
    distinction between physical and digital items arise
    again--is location useful for digital, UB thinks probably
    not (p. 90 of packet)

    Issues we did not bring up but they did: 
    -- Renamed AP 
    -- Other minor modifications 

-- Vote

   QUESTION: Conforms to the DCMI Abstract Model? 
   AGREE 4 
   DISAGREE 1 
   ABSTAIN 1 
   
   QUESTION:Is this internally consistent? 
   AGREE 5 
   DISAGREE 1 
   ABSTAIN 0 
   
   QUESTION: Is it documented according to our guidelines for application 
   profiles? 
   AGREE 4 
   DISAGREE 0 
   ABSTAIN  2 
   
   AGREED: It conforms. 

   ACTION: To draft a review that contains: (Andrew) 
   1. Descriptive piece which demonstrates that we have read the profile 
      and understood  it
   2. Present the result ("it conforms") 
   3. Then present considerations, e.g., acknowledge that
      DCMI's DCAP guidelines are currently still a moving
      target and that they have met the guidelines "such as
      they are" or words to that effect.

   ACTION: Tom will communicate these results to Sarah and Muriel 

----------------------------------------------------------------------
-- DCAM Profile Model (Andy and Tom) 

   Andy reports on "Description Set Profile" meeting, 15 March, Barcelona

   Criteria 1.0 for conforming AP 
   1. Conforms to the DCMI Abstract Model (DSP) 
   2. Internal consistency (e.g., DSP relationship to FR) 
   3. Documented according to our guidelines for application profiles 
      (totality of doc from below) 
   
   AP Model 
   1. Functional Requirements (desirable) 
   2. Domain Model (mandatory) 
   3. Description Set Profile (mandatory) 
   4. Usage Guidelines (optional) 
   5. Encoding Syntax Guidelines (optional) 
   
   STATED REASONS FOR AN AP: 
   1. conform to abstact model = is one (perhaps not only) operationalization 
      of interoperability 
   2. encourage reuse of APs (through modular approach like in the DSP) 
   3. AND reuse of individual properties 
   4. document how metadata is used in a particular application 
   
   NEED: functional requirements for application profiles 

----------------------------------------------------------------------
6. USAGE BOARD PROCESS 

-- Current process document
   http://dublincore.org/usage/documents/process/

-- Notes from Stuart
   http://dublincore.org/usage/meetings/2007/03/barcelona/Process_Doc_Revisions.txt

-- Proposal from Makx
   http://dublincore.org/usage/meetings/2007/03/barcelona/2007-02-14.dcdir-process-makx.txt

   Tom will start a discussion on dc-usage-bc.

----------------------------------------------------------------------
7. WORK PLAN 
   http://dublincore.org/usage/meetings/2007/03/barcelona/FrontPage.pdf

----------------------------------------------------------------------
8. RDA 
   See discussion paper by Diane et al
   -- http://dublincore.org/usage/meetings/2007/03/barcelona/Framework_20070311.pdf

   Not UB business - will discuss at dinner.

----------------------------------------------------------------------
9. AOB 
   Next meeting will be held Saturday and Sunday, 25-26 August 2007, in Singapore 
   http://conferences.nlb.gov.sg/dc2007/