Meeting notes, DC Usage Board, Manzanillo, 30 September - 1 October 2006
http://dublincore.org/usage/minutes/html/2006-10-01.meeting-notes.manzanillo.html

Agenda: http://dublincore.org/usage/meetings/2006/09/manzanillo/html/

----------------------------------------------------------------------
Day 1 - Saturday, 30 September 2006

Attendance
    Akira Miyazawa
    Andrew Wilson (scribe)
    Andy Powell (via Skype)
    Diane Hillmann (scribe)
    Joe Tennis
    Stuart Sutton
    Tom Baker (chair)

Guests
    Jon Phipps
    Leif Andresen
    Pete Johnston (via Skype)

----------------------------------------------------------------------
1.  Editorial changes to DCMES (Scribe: Andrew)
    http://dublincore.org/usage/meetings/2006/09/manzanillo/dcmes-changes/html/

    Aim: to address the comments received about the proposed
    changes to the DCMES document.

    ISSUE: Pete Johnston had some concerns about inconsistency
    in language use in the proposed DCMES changes. In some
    places we use 'controlled vocabulary', in other places
    we use 'encoding scheme'.  Pete believes we should make
    the language consistent within the need to have the
    DCMES conform to the DCAM. Pete suggests using specific
    references to 'vocabulary encoding scheme' or 'syntax
    encoding scheme'.

    AGREED: The slight ambiguity introduced by use of
    'controlled vocabulary' is desirable. In order to ensure
    consistency, the occurrence of the phrase 'controlled
    vocabulary' in the DCMES document will remain.
    To make the current wording consistent with the DCAM there
    should be a definition of 'controlled vocabulary' included in
    the DCAM. The definition will need to subsume the concept
    of 'classification'. Occurrences of the phrase 'encoding
    scheme' will be replaced with 'controlled vocabulary' so
    the document is consistent throughout.

    ACTION 2006-09-30: Diane, Stuart, and Joe to draft
    a proposed definition of 'controlled vocabulary' for
    discussion.

    Controlled vocabulary: "a list of terms that have
    been enumerated explicitly or a method of organisation
    according to a set of predetermined principles usually
    characterised by a notation system and a hierarchical
    structure of relationships among the entities."

    ISSUE: Does this definition apply to strings, concepts
    and/or things?

    ACTION 2006-09-30: Andy and Pete to include agreed definition of
    'controlled vocabulary' in the terminology section of
    the DCAM for the next release.

-- Proposed new wordings for specific elements in the DCMES

    Note: all change actions recorded in this
    section refer to the "new" wordings proposed in
    http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/.

    ACTION 2006-09-30: Tom - Change dc:subject comment: "Recommended
    best practice is to use a controlled vocabulary"
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    ACTION 2006-09-30: Tom - Change dc:language Comment: "Recommended best 
    practice is to use a controlled vocabulary such as RFC 3066"
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    ACTION 2006-09-30: Tom - Change dc:coverage, dc:format,
    dc:type comments: say 'controlled vocabulary' instead of
    'encoding scheme'
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    ACTION 2006-09-30: Tom - Change definition of dc:contributor, deleting
    the incorrect use of 'primarily'
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    AGREED: To leave the words "at any level of granularity" in the 
    comment for dc:date.

    ACTION 2006-09-30: Tom to create a decision document
    on the basis of the public comment document, making all
    changes recorded here and correcting the bullet points
    (summaries of changes made) accordingly
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    ACTION 2006-09-30: Tom - On the basis of the decision document,
    Tom to issue a new set of terms
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    ACTION 2006-09-30: Tom - On the basis of the decision document,
    Tom to create a consolidated report of all changes made
    to DCMES since approval by NISO -- including changes made
    between 2001 and 2004. This report will be submitted to
    NISO for approval as a new NISO Standard.

    ACTION 2006-09-30: Tom to go through DCMI Terms document
    and prepare a document setting out proposed changes
    (most of which are dependent on the DCMES changes) for
    public comment.

-- Discussion of Treasury Board of Canada comments on the
   proposed changes to DCMES

    AGREED: For dc:source, the word 'related' in the definition
    is redundant and should be removed. The new definition
    for Source will be the wording proposed in the Canadian
    Treasury Board comments: "The resource from which the
    described resource is derived.".

    ACTION 2006-09-30: Tom - Change dc:source definition to read:
    "The resource from which the described resource is derived"
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    DISCUSSION: With regard to dc:relation: The wording has
    been widely discussed in the past and none of the other
    proposed wordings express the concept more clearly. The
    words "associated with" proposed by the Treasury Board
    of Canada do not add to the semantic precision and have
    connotations that are too narrow.

    AGREED: Usage Board agreed to retain the current proposed
    definition for dc:relation.

    DISCUSSION: With regard to dc:format: the Treasury Board of
    Canada proposed wording is too broad. The words 'file
    format' in the definition are intentionally specific to
    electronic resources, as are the words 'physical medium'
    and 'dimension' to physical resources. These represent the
    three things that are in scope for the term. 'File format'
    is a word of art for digital media formats and does not
    have the usual meaning of 'format'. 'File format' is the
    name of something and should not be changed because it
    repeats a word in the term name. A further problem with
    the definition proposed by the Treasury Board is the word
    'characteristics', which includes things that are not
    about format. 'Hot', for example, could be a physical
    characteristic of a resource but has nothing to do with
    dc:format.  
    
    AGREED: The Usage Board agreed to retain the current
    proposed definition for dc:format.

    DISCUSSION: With regard to dc:type: the terms in the Treasury
    Board's type vocabulary are perfectly valid for use with
    Type. The UB believes that each of the terms is a valid
    genre term and sees no need to change the definition of
    Type or for the Treasury Board to change its own Type
    vocabulary.  
    
    AGREED: The Usage Board agreed to retain the current
    proposed definition for dc:type.

    ACTION 2006-09-30: Joe to locate and circulate a current
    definition of 'genre'.

    Comment from the Treasury Board of Canada:

    > 2.4 We recommend changes to the proposal for Coverage. While
    > we support clarifying the definition of Coverage, the
    > revised wording "spatial or temporal topic of the resource"
    > does not capture the full scope of usage of this element
    > within the Government of Canada. The spatial aspect of
    > Coverage is also used for resources that apply to a certain
    > geographic area.  For example, a resource that contains
    > information on employment opportunities for various regions
    > contains information that is organized by area. The Coverage
    > element will contain a geographic descriptor, geocode or
    > spatial coordinates that define the areas referenced by the
    > resource. This could enable a user to search on employment
    > opportunities for a specific area.  Suggested definition:
    > The spatial or temporal characteristics of the resource,
    > or the jurisdiction under which the resource is relevant.
    > We support the inclusion of jurisdiction in the definition.
    > We would strongly encourage the Usage Board to consider
    > creating a refinement for Jurisdiction so that it is clearly
    > distinguished from the Spatial refinement.

    DISCUSSION: With regard to dc:coverage, the term is not
    strictly about "aboutness". The Canadian Treasury Board
    example does fit under dc:coverage and does not invalidate
    the proposed definition (which is: "The spatial or temporal
    topic of the resource, or the jurisdiction under which
    the resource is relevant").  The problem is that temporal
    applicability overlaps with dcterms:valid, and including
    temporal applicability in a definition of dc:coverage
    would introduce a definition overlap. But we can say
    that applicability is included in a broader view of
    "aboutness". Our view of the Treasury Board proposal is
    that their use of applicability is valid under the current
    scope of topic and their examples are all valid under our
    wider view of "aboutness". Tom's preference is to argue
    that the examples fall under current usage of topic so
    we don't need to change the definition of the term.

    ACTION 2006-09-30: Tom - Add "or a geographic place to which
    the resource applies" to the comment for Coverage
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    ISSUE: There are 2 options:

    1. Stay with current definition and argue that
       applicability is covered by the proposed definition
       and address the issue in the comments.  The concern
       is that this ignores the problem about "aboutness"
       and applicability.

    2. Use Andy's proposed new definition which is:

       "The spatial or temporal topic of the resource,
       the spatial applicability of the resource, or the
       jurisdiction under which the resource is relevant."

    Straw Poll on options for definition of Coverage:

    1. Stay with current proposal and amend comments: 
       Agree       2 
       Disagree    4 
       Abstain     1

    2. Accept Andy's proposed new wording 
       Agree       5 
       Disagree    0
       Abstain     2

    Vote: to accept Andy's proposed new wording.  
       Agree       7 
       Disagree    0
       Abstain     0

    ACTION 2006-09-30: Tom - Change definition of dc:coverage 
    to: "The spatial or temporal topic of the resource, the spatial
    applicability of the resource, or the jurisdiction under
    which the resource is relevant."
    [see http://dublincore.org/usage/public-comment/2006/08/dcmes-changes/].

    ACTION 2006-09-30: Tom to write a public response to the
    comments received, including the above reasoning for not
    accepting proposed changes for Relation.

----------------------------------------------------------------------
2.  Domains and Ranges (Scribe: Andrew)
    http://dublincore.org/usage/meetings/2006/09/manzanillo/domains-ranges/html/

    AIM: To consider the addition of domains and ranges to
    the DCMI properties.

    ISSUE: We need to agree in principal if we are going to do
    this, and whether it will apply to all terms or only those
    in the DCTerms namespace. There is a concern that most
    implementers are not familiar with the concepts and that
    we will be complicating the issues. It was noted that the
    point of adding domains and ranges is to say formally what
    the human language definitions already say. The proposal
    exposes semantics of properties in a machine readable way
    and will help clarify our thinking about both existing
    properties and any new properties.

    On the question of whether to apply domains and ranges
    to all properties or only those in DCTerms namespace,
    the second option (i.e., apply onto to DCTerms) leaves
    the current fuzziness in use of DC properties and allows
    continued use of literal strings as values for terms
    in the DC namespace. The UB agreed in principle at the
    Seattle meeting to start this work and Tom has drafted a
    work plan (page 69 of work packet).

    The UB can have an opinion but this one needs to be
    worked out with the wider DC community. It is necessary
    to understand what the impact of these changes might be
    on the implementation community. A package of changes is
    to be taken to reviewers to assess impact and this process
    is to start in fourth quarter 2006.

    QUESTION: Is it possible to have multiple ranges?  Answer:
    Yes, but a resource must then conform to all of the ranges.

    AGREED: The UB needs to involve implementers more
    systematically, more formally and earlier on in the
    processes, including getting implementers on the Usage
    Board.

    Flagged Issues

    1. If we are asking implementer communities to review domain
       and range assignments we may find a gap in understanding
       the fundamental purpose of domains and ranges.
       Documentation needs to be addressed not just to experts,
       but also to people who have no understanding of the
       purpose of this exercise.

    2. dc:description: just Resource.

    3. Eliminate 'NonAgentResource' from range assignments and
       replace with 'Resource'.

    4. dc:title, dct:abstract, dct:alternative, dct:tableOfContents:
       What is the range? Issue with strings, literals, string
       objects etc. Should the range be 'resource'?

    5. dc:type: Should the range to be changed to 'Class'? What is
       the correct range for dc:type -- should it be limited to
       the definition of the Type?

    6. dct:audience, dct:educationLevel, dct:mediator:
       Change AgentGroup to AgentClass?

    7. dct:bibliographicCitation
       Comment says "as unambiguously as possible"; the
       definition of 'reference' says "unambiguously in a
       given context" (taken from definition of dc:identifier) --
       the range here is a narrower set of values. The notion
       of using unambiguous in definition of reference poses
       problems for it and its refinements because bibliographic
       citations are not unambiguous; should the domain be
       bibliographic resource?

    8. dct:educationLevel
       NB. Definition is on page 48 of meeting packet. Note
       the problem with name of class (see Audience).

    9. dct:license:
       Does it need a range that is narrower than
       rightsStatement? Need to add a class 'license' which
       will reuse the definition of the license property to
       define a new class of license.  Range for dct:license
       property will be 'license'. License is a subclass of
       rightsStatement.

    10. Definition of rightsStatement reworded to "a statement
        about the intellectual property rights held in or over
        a resource, or a statement about access rights".

    11. Provenance:
        Spelling mistake in provenanceStatement. Definition
        includes 'NonAgentResource'.

    12. tableOfContents:
        Should range be 'resource'?

    13. Jurisdiction:
        Remove first clause, 'an administrative entity'.

    ACTION 2006-10-01: Andy to consider UB suggestions (as 
    documented in
    http://dublincore.org/usage/minutes/html/2006-10-01.meeting-notes-manzanillo.html)
    in revising the Domain and Range vocabulary.

----------------------------------------------------------------------
Day 2 - Sunday 1 October 2006

Attendance
    Tom Baker
    Diane Hillmann
    Andy Powell
    Joe Tennis
    Stuart Sutton
    Andrew Wilson
    Akira Miyazawa

Guests
    Makx Dekkers
    Pete Johnston
    Jon Phipps

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

    Flagged Issues

    14. The term rightsStatement should point to a binding rights
        statement about intellectual property.
    
    15. New definitions for the terminology section of the DCAM
        will arise from the domains and ranges discussion and need
        to be addressed.

----------------------------------------------------------------------
3.  Encoding Schemes (Scribe: Andrew)
    http://dublincore.org/usage/meetings/2006/09/manzanillo/encoding-schemes/html/

    ISSUE: How should the existing encoding schemes be classified
    into vocabulary or syntax encoding schemes?

    ACTION 2006-10-01: Suggestion to DCAM authors: Syntax Encoding Schemes:
    Amend definition to include 'or enumerated list of strings' after 'string'.

    ACTION 2006-10-01: Suggestion to DCAM authors: Vocabulary
    Encoding Schemes: Amend definition to read: "A vocabulary
    encoding scheme is an enumerable set of resources".
    Need to acknowledge that the string(s) specified by a
    SES actually have an underlying concept space.

    ISSUE: Does a SES map to RDF datatype?

    ACTION 2006-10-01: Joe and Pete to summarise concisely the
    relationship between SES, VES and things as illuminated
    by the UB discussion. Must address the issue of whether
    syntax encoding schemes map to RDF datatypes.

    Agreed categorisation of existing schemes:
        Box         SES
        DCMIType    VES
        DDC         VES
        IMT         VES
        ISO3166     SES
        ISO639-2    SES
        LCC         VES
        LCSH        VES
        MESH        VES
        NLM         VES
        Period      SES
        Point       SES
        RFC1766     SES
        RFC3066     SES
        TGN         VES
        UDC         VES
        URI         SES
        W3CDTF      SES

    ACTION 2006-10-01: Suggestion to DCAM authors: see UB
    categorisation of existing schemes (see
    http://dublincore.org/usage/minutes/html/2006-10-01.meeting-notes-manzanillo.html).

    NOTA BENE: ISO3166 and ISO639-2 changed to SES from original proposal

----------------------------------------------------------------------
4. Review of Collection Description application profile (Scribe: Diane)
   http://dublincore.org/usage/meetings/2006/09/manzanillo/profile-cdap/html/

   Andrew, shepherd, began with a general explanation of the
   tasks and task assignments, as documented in various emails
   and the meeting packet.

   General comments on questions asked:

   Tom: We need to visualize the end product and consider the
   questions asked in this context.  The end product should
   be a short description.  The end product should provide
   information that can be viewed on its own terms, outside
   the context of the AP itself.  The goal is still to consider
   conformance, but assignments should have instructions that
   explicitly ask a reviewer, for example, to "Summarize X".

   Stuart: There is internal evidence and external evidence
   that can be used to formulate and answer the questions.
   In the case of this AP there is a great deal of external
   evidence, going back years.  How should such external
   evidence be incorporated into the report?  Tom: we need
   to rely increasingly on internal evidence, without the
   kind of research that we did in the past to determine
   independently what community needs might be, or what
   discussion was around a particular issue.  The assumption
   is that APs will be coming across the transom more often
   than being created as part of a DC working group.

   General concern about how to deal with the reality of some
   APs coming from outsiders without any evidence of support
   versus others with full support of a WG and lots of buy in.
   How much should that matter? Should it matter for any other
   reason than determining priority for review?  Should we
   ask whether an AP meets community needs if we don't have
   any criteria for judging the results?  Consensus is that
   we should not emphasize "meeting of community needs" as a 
   criterion.

   Priorities for review will likely be based to some
   extent on what strategic directions DCMI has taken. Makx
   thinks that we are working on these profiles in order to
   develop guidelines and good examples of APs for others,
   not necessarily so that we can evaluate large numbers of
   APs. Tom mentioned an effort going on in German-speaking
   libraries to use any model developed by DCMI in evaluating
   APs.  He sees the questions and criteria as very important
   for replicating this model in a more distributed, less
   centralized way.

   Tom suggested that we get into the review itself, which
   will surface more specific discussion on criteria.

   AGREED: The Shepherd (Andrew) is to deal with issues arising
   from the review and ensure that these are communicated to
   the working group.  Basis:
   http://dublincore.org/usage/minutes/html/2006-10-01.meeting-notes-manzanillo.html.

   There was discussion on Andy's contention that an
   application profile needs to document its data model. Diane
   contends that we need not specify a "data model" per se,
   but use less technical language requiring information that
   defines what they're describing and what the boundaries are.
   Tom agrees that we need to make the requirement accessible
   to people not familiar with formal data modeling. Andy
   suggestions we call it an "application model" -- a model of
   the resources described and the relationships between them.

   ACTION 2006-10-01: Andy will revise Andrew's paragraph in
   the review report about the model used for the CD AP; a
   better explanation is needed. This is to include a statement
   about how the model in the application profile diverges or
   amends the AMCC model used as the basis for this application
   profile.

   ACTION 2006-10-01: Andrew to track the new actions arising
   from the meeting and ensure their completion.

   ISSUE: We need to describe better how functional
   requirements fit into the application profile description,
   and where that relates to the application model. Application
   profile review should be able to review whether application
   model supports the functional requirements stated.
   Should the same person be looking at both those things
   in the review?  We should not need to look outside the AP
   documentation to perform this assessment.

   We should make it clear that we are not aiming to anoint
   particular application profiles as the only ones useful
   for a particular community.

   Tom: Our criteria and requirements for APs should be as
   simple as possible, so as to be understandable by those
   who would try to apply them. Question is how high we want
   to set the bar. Tom's preference is to set it fairly low,
   and include good examples that go above that.  Went through
   Joe's comments with the idea of seeing where the boundaries
   fall between requirements and ideals.

   Best practice is to have a purpose and scope, at a
   summary level.  Question about how much the AP should
   be stand-alone, and how much reference should be made
   to precursor models, if relevant.  This is particularly
   appropriate for the CD AP, but should be included in
   generic requirements.

   Tom: UB review needs to recognize that there may be a
   relationship between an externally expressed model and
   the AP, and the AP documentation might need to have some
   additional material to assist in relating the model to
   the AP where dependencies exist.  This implies that it
   should be within the scope of the review to consider that
   external document.

   Tom: CEN guidelines should be revised to reflect what we
   determine to be best practices as we work through this
   profile, so we should not feel constrained by the current
   CEN guidelines.

   Some discussion about how the CD AP models levels of
   descriptions and how confusing this is.  The WG will
   attempt to disambiguate this in the next iteration,
   perhaps by splitting the current AP into two.  Some thought
   expressed that the last-version separation of collection
   descriptions into more than one kind within the same AP
   was a mistake.  Question whether these collections are
   of "items" or "resources" -- items seems to have been
   inherited from FRBR.  This relates to Joe's point about
   "content" not being defined, and the consensus was that if
   the collections were of "resources" rather than "items"
   there need be no additional definition of "content."
   Statement that this was a break from the AMCC model needs
   to be included, and approved by the WG.

   Consensus was that Joe's concern about scope as reflected
   in his point 2 were not something we needed to discuss.

   Akira had a concern about the label for
   "Collection-Description", which in a previous version
   of the application profile was "Catalogue or collection
   description". For Akira, its easier to grasp the meaning of
   the old label because it shows a typical case. He thinks it
   may be confusing that "Collection-Description" is not the
   "Description" of the collection, though it is a sub-property
   of it. And it is not just a description of the collection,
   but also have to be a second collection.

   Akira's comment about the change in the label for
   "Collection-Description" will be addressed.

   Question about whether Diane's comments are relevant
   for formal review, consensus was no.  Question about
   relationship between "Using Dublin Core" and the AP,
   what can be assumed when there is no guidance in the
   AP and UDC has guidance.  Question whether advisory or
   red-flag things should be sent back to the AP originators,
   whether this is a special case, and whether these are only
   relevant to APs that come up through WGs.  Concern that
   some of the comments are late and might better have been
   part of the WG process -- point made that this is sometimes
   unrealistic because of time constraints.

   Long discussion about whether the isLocatedAt property
   should be generalized, whether it should be limited to
   physical locations, and what the implications are of
   approving it in this AP without dealing with it in a more
   general manner.  Other APs need this, and it has been a
   persistent problem.  Other question is what mechanisms
   should be used for dereferencing (if we think that's
   important).  These are related to a number of thorny
   web-architecture issues that we need to consider.

   We need to determine when it is okay to use a
   general property narrowed down, and when a new
   property is necessary.  Discussion of not redefining
   properties was asserted in the context of discussion of
   dcterms:isReferencedBy, where there was some confusion
   about whether "Usage in this DCAP" is clearly _not_ a case
   of re-definition.

   Andy pointed out that in the past we discouraged people
   from creating new properties. We might better encourage
   them to _do_ so. 
   
   There is a question about whether we are explicitly
   endorsing subproperty assertions when we say that usage
   in an AP is conforming.  If so we should say that up-front.

   ACTION 2006-10-01: Andrew to formally write up the
   outcomes of the review process to include a good
   stand-alone description of the application profile and
   a characterisation of the types of conformance testing,
   with a description of the testing process. Andrew is to
   prepare feedback to the Working Group independently of
   the formal statement.

   ACTION 2006-10-01: Stuart to review the section of the
   process document which concerns the requirements for
   conforming status for application profiles, as part of a
   general review of the language of the process document.

   ACTION 2006-10-01: Tom and Andrew to work on refining the
   set of questions for reviewing application profiles and the
   way in which they are asked. Three essential criteria are:
      1. conformance to the abstract model 
      2. internal consistency
      3. relationship of terms in the application profile to
         existing DC terms.

   ACTION 2006-10-01: Andrew to draft a review document
   for the CD application profile and circulate it to the
   UB. Andrew to prepare feedback for the CD working group
   and circulate it to the UB.

----------------------------------------------------------------------
6. Workplan (Scribe: Andrew)
   http://dublincore.org/usage/meetings/2006/09/manzanillo/workplan/html/

   ISSUES:

   3.1 We need to finalise the domain and range vocabulary by
       January - discuss via email and/or conference call. Needs to
       be ready to go out by Xmas.
   
   4.1 RDF schemas for domain and range vocabulary, and
       DCTerms assignments will be prepared after UB has approved
       a domain/range vocabulary to go out for public comment.

   ACTION 2006-10-01: Tom to check DCTerms definitions for consistency
   with changed DCMES definitions, and prepare a document to
   summarise nature of changes made. To be done via the UB
   Wiki? Andy has a suggestion about how to prepare a before
   and after document using HTML Diff.

----------------------------------------------------------------------
7. Removing MODS Elements from DC Libraries Application Profile
   http://dublincore.org/usage/meetings/2006/09/manzanillo/profiles-dclib/html/

   ISSUE: UB needs to move away from notion that it is a bad
   idea to keep creating new properties. UB should be more
   open to APs proposing new properties, instead of trying
   to reuse existing properties in other namespaces.

   DC Lib to create new properties. How this is done is up
   to them. UB endorses the proposal put forward by Robina
   Clayphan.

----------------------------------------------------------------------
8. UB Principles Document
   http://dublincore.org/usage/meetings/2006/09/manzanillo/other/html/

   ISSUE: The document
   http://dublincore.org/usage/documents/principles/
   has been superseded by DCAM but is referred to in
   the Using Dublin Core document and is used as the base
   URI for identifiers used for typology of terms in terms
   documentation.

   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.  
   
   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.

   ACTION 2006-10-01: Andy and Pete to add HTML anchors to
   the DCAM document for the next release of the DCAM.

   ACTION 2006-10-01: Andy, Pete and Tom to create a new
   DC namespace for term classes, agree on namespace URI,
   declare PURLs for the term classes, update namespace policy
   and agree on maintenance policy for the new namespace.

   ACTION 2006-10-01: Andy and Pete to create RDFS declaration
   of term type classes.

   ACTION 2006-10-01: Eventually, once term type classes
   have been approved, Tom to insert PURLs in the DCTerms
   documentation replacing the current URIs to the principles
   document.