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
|