Agenda:       http://stage.dublincore.org/usageboard/log/.html/2006-03-23.ub-telecon-agenda.txt.html
This report:  http://stage.dublincore.org/usageboard/log/.html/2006-03-23.ub-telecon-report.txt.html

              Usage Board telecon - report
              2006-03-23 Thu 1400 UTC

Regrets: Andrew

-- DCMI property domains and ranges (Andy)
   http://dublincore.org/architecturewiki/DCPropertyDomainsRanges
-- Finalizing DCMI Type Vocabulary after the comment period (Stuart)

   2006-03-13. Andy has been working on this and proposes
   that we put it on the agenda for Seattle.

   Andy has assigned domains and ranges to all DCMI terms.
   We want a reasonable set of domains and ranges.  In Seattle,
   our goal should be to agree this is a reasonable thing
   to do.  We should weigh whether we want to do this at all --
   what are the implications of doing it.  One main issue is
   "educationalLevel".

   Diane: in looking through possible classes, I see that 3 out of
   4 use FRBR -- I was trying to see where these were assigned.
   Andy: I thought all these classes were used somewhere but
   need to check.  Some may only be used in definitions of other
   classes - so not directly assigned.  For example, "work" is
   there in order to define "manifestation".  Need to double-check
   which classes are actually used. -- check to make sure there
   are no "hanging classes" that do not get used anywhere.

   Diane: Problems arise with FRBR expressions: often,
   "manifestations" relate to expressions, not necessarily to
   works.  Eg, translation as an expression.  Manifestation of
   that translation skips a level in terms of FRBR.  Difficult
   to always distinguish btw manifestation and an Item; things
   can be both Manifestation and Item in the digital context.
   Most work on FRBR has come from a library context.  Joe: in
   the archival community, everything is a "copy".  Resources --
   digital resources and physical resources -- but we do not
   necessarily need to talk about items and manifestations.
   What are the consequences about being explicit about domains
   and ranges?  Diane: good to discuss but agree with Tom -- one
   step at a time.  Andy: the minimal aim - if we cannot agree
   on actual classes - is to decide where this document is going.

   Second issue: style of definitions.  Tom: we should decide
   on a style:

      -- Current DCMI Type Style: "A service is a system that provides..."
      -- DCMI Type Style, Renaud style: "A resource which is a system..." [2]
      -- Domain-Range Vocabulary style: "The class of all services..." [1]

   Andy: I'm not convinced these are "just" stylistic changes.
   Example: saying that a "service" is a "system" is not defining
   the class.  We are just correcting the definition - not
   changing how the definition is interpreted; making explicit
   what is currently implicit in a definition.

   RESOLVED This document now belongs to UB.
   ACTION Andy Consider removing the FRBR-related classes.

   ACTION: Tom - do two or three of the type vocabulary in the
   "domain/range vocabulary" style - in Seattle, we look at
   three and make a decision.

-- Replicating ELEMENTS1.1 terms in the DCTERMS namespace (Tom, Andy)

   On Tue, Jan 03, 2006 at 05:10:24PM -0000, Andy Powell wrote:
   > http://dublincore.org/architecturewiki/NamespacePolicy
   > 
   > During the Architecture WG f2f meeting in Madrid, we discussed the
   > possibility of adding the 15 DCMES terms to the DCTERMS namespace (in
   > addition to them being in the existing DCMES namespace).  This would
   > mean that many DC users would only need to use a single DCTERMS
   > namespace.  However, as far as I recall, there was no clear agreement
   > about whether this should be done or not.
   > 
   > Such a change, if we decided in favour of making it, would require
   > further changes to the namespace policy.

   Architecture to come up with arguments for and against this action.
   Architecture list to comment as input to the UB Meeting in Seattle.
   Need a coherent line on why we're bothering to do this.
   Change would have a cascading effect on our documentation,
   we'd need to identify places where we'd need to change docs.

   ACTION: Andy - post a discussion for the rationale to
   Architecture list for replicating Elements 1.1 in DCTERMS
   This input on the list would become input at UB in Seattle

-- 
Dr. Thomas Baker                                 [log in to unmask]
Director, Specifications and Documentation
Dublin Core Metadata Initiative