Title: DCMI Usage Board Meeting, 29-30 April 2006, Seattle
Identifier: http://dublincore.org/usage/minutes/html/2006-04-30.meeting-notes-final.html
Source: file://localhost/i:/admin/usageboard/log/2006-04-30.meeting-notes-final.txt

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

----------------------------------------------------------------------
Agenda Item 1: Changes to Terms in the DCMES Namespace

a) Texts needed. Three texts are needed:

1) Announcement of public comment (two paragraphs) --
something like [1]

2) Public comment text: Proposed Changes to Terms in the
DCMES namespace -- expanding on [1] in the introduction.
The introduction should introduce each of the major
issues covered by the changes. Each of the problem
statements (for individual terms) should then point
back to the main issues listed in the introduction.

After public comment, #2 will be turned into:

3) A Usage Board Decision text

[1] http://dublincore.org/usage/meetings/2006/04/seattle/dcmes-changes/comment-announcement-text.txt

ACTION: Tom to supply outline of these changes

b) Key issue: "content" versus "intellectual content"

The Usage Board feels that the distinction between the
"intellectual content of the resource" and the "content
of the resource" is a non-issue.

On the other hand, "resource" is broader than "content of
the resource".

However:

(a) People have already used a more generalized definition
because they are describing resources that are not
document-like content objects.

(b) Our experience indicates that this is a problem for
people who are trying to apply these definitions.

(c) We recognized that there are examples of things for
which the current definition do not work [rock, stuffed
animal], so this needs to be fixed.

(d) This will bring definitions in line with practice.

In order to not violate the Namespace Policy, we are not
making substantial impact.

c) Term by term

COVERAGE

Break last sentence of proposed comment into two, because
as it stands it is awkward.

Change proposed comment in COVERAGE to: "recommended best
practice is to use a controlled vocabulary such as..."

ACTION: Andrew

DESCRIPTION

Description: in the problem statement in first
sentence point back to content resource statement [apply
consistently throughout] -- see discussion above.

FORMAT

Question for further discussion: Dimension vs. extent --
relevant to domains and ranges.

Current domains and ranges document puts extent subordinate
to dimension [Andy]. Dimension includes: duration,
size, extent OR media type [file format, physical medium,
or dimensions].

AGREED: Definition: "file format, physical medium, or
dimensions of the resource".

AGREED: intent of UB is to clarify the definition, not
narrowing it. The public comment announcement should ask
where and how people have used FORMAT. We do not think
that we have broken anything but need to ask. Concept of
manifestation in FORMAT in problem statement is confusing.

AGREED: Problem statement for format should simply
say: "people have found this definition confusing".
For example, people have used this to identify a URI for
a version of the resource.

AGREED: Comment for FORMAT should not provide advice
on use. Delete first sentence. [this should be followed
throughout].

No parentheses in comments in FORMAT.

Take out, phrase immediately after IMT statement in
FORMAT comments.

LANGUAGE

Issues are examples - RFC 3066, ISO 639-2

AGREED: change wording to eliminate codes, and put in
both standards [RFC and ISO above].

AGREED: We propose to change it to: "Recommended best
practice is to use an encoding scheme, such as RFC 3066
or ISO 639-2."

AGREED: Language of the problem statement needs to
be polished. Get rid of everything after the sentence
starting with "However" [the last three sentences].

AGREED: add a bullet point to the problems statement for
language citing the language for the content resource
issue.

RELATION

In proposed comment: is the statement "or number" redundant?
AGREED: get rid of "or number"

AGREED: "recommended best practice is to identify the
related resource by means of a string conforming to a
formal identification system."

AGREED: "as per the DCAM" is terse in the problem statement.

AGREED: In all these we should declare that any of the
changes in the individual terms should point back to the
introduction [general statement of the problem].

RIGHTS

Capitalization -- why?

AGREED: change to "various intellectual property rights",
eliminate "Intellectual Property Rights (IPR), Copyright,
and various Property Rights."

AGREED: get rid of "rights management", change to "rights".
(What does "rights information" add where "rights" would
be sufficient?)

AGREED: on comment to say: "Typically, rights information
includes a statement about various property rights
associated with the resource, including intellectual
property rights."

SOURCE

AGREED: wordsmith this. In proposed comment: Delete "or number"

AGREED: Definition: "A related resource from which the
described resource is derived."

Comment: "The described resource may be derived from the
related resource in whole or in part. Recommended best
practice is to identify the related resource by means of
a string conforming to a formal identification system."

SUBJECT

Inconsistent in capitalization.

AGREED: Comment: Should be "typically the topic will be
represented using key words, key phrases, or classification
codes."

Are we happy with proposed definition.

AGREED: we are happy with proposed definition.

Problem statement: Last sentence of the problem statement
- should reflect recommended best practice.

In comment: "recommended best practice is to use an
encoding scheme such as a classification or a controlled
vocabulary, and to use Coverage to describe the spatial
or temporal topic of the resource."

TYPE

Take "for example" out of parenthetical.

Comment: Instead of "select a value": "use a controlled
vocabulary".

Change last sentence proposed comment to what we changed
Format to: "file format, physical medium, or dimensions"

Comment: Delete first sentence of comment.

Categorization that is not topical that is not a genre,
function, or aggregation level -- e.g., -

Functional category -- e.g., - work, expression,
manifestation, item?

Genre -- e.g., lesson plans, simulations, standards.

Proposed definition: The genre, functional category,
or aggregation level of the resource.

Comment: "Recommended best practice is to use a controlled
vocabulary such as"

AGREED: Vet proposed definition with community for comment
and examples of the use of Type that don't fit into genres,
functional categories, or aggregation levels.

DATE

Definition: A point or period of time associated with an
event in the lifecycle of the resource.

Comment: Date may be used to express temporal information
at any level of granularity. Recommended best practice
is to use an encoding scheme, such as the W3CDTF profile
of ISO 8601 [W3CDTF]

ACTION: Tom heads up to the Date working group people

----------------------------------------------------------------------
Agenda item 2: Changes to DCTERMS Namespace

Term: URI
Delete second slash in RFC 39 in both references.

Term: ALTERNATIVE TITLE

Potential problem with the comment to alternative title --
it seems odd, but not necessarily wrong. It seems like
it is addressing a question and is not as consistent
with other comments.

There are: (a) parallel titles, and (b) translated
titles. Is Alternative Title used for primary-ness or
secondary-ness? The intention was to allow a distinction
between primary and secondary titles (the secondary title
is there for access purposes).

AGREED:

Proposed definition:
An alternative name for the resource

Proposed comment:
The distinction between titles and alternative titles
is application-specific.

EDUCATION LEVEL

Problem: AUDIENCE is defined as a class of entity for
whom the resource is intended. EDUCATION LEVEL is a
refinement of audience. The definition of EDUCATION
LEVEL is therefore broken.

AGREED: EDUCATION LEVEL is a refinement of AUDIENCE.
Need to change the definition of Education Level.
Change to:

An audience, defined in terms of its progression
through an educational or training context, for whom
the resource is intended.

ACTION: Tom to go through DCTERMS to normalize their style.

----------------------------------------------------------------------
Agenda Item 3: Replicating DCMES in the DCTERMS Namespace

The Usage Board supports the idea that DCMI replicate the 15
DCMES elements in the DCTERMS namespace.

Communities need to be convinced that this is a good idea.
We need to have data and feedback from implementers about
potential impact -- for example, from commercial users and from
aggregators such as NSDL. We should not rush this decision.
The Directorate should consider the timeline, priorities,
how to do an impact analysis, and resource requirements.

----------------------------------------------------------------------
Agenda Item 4: DCMI Property Domains and Ranges

The question discussed: Do we want to assign domains and
ranges to DCMI properties?

Arguments for:
-- semantics of the DC properties are more specific and explicit
-- support for Semantic Web inferencing

Arguments against:
-- DC is fuzzy, has traditionally been quite fuzzy,
and we may or may not want to lose that fuzziness

If we decide to do this, should DCMI create the domain/range
classes from scratch? Or should we use existing classes,
adding where necessary?

Work to date has been on creating roughly thirty
classes (terms) in a domains and ranges vocabulary [1].
The alternative would be to re-use existing classes (i.e.,
not create new URIs).

We note the existence of several other vocabularies that
might be defined and identified with URIs:

-- DCMI Abstract Model entities
-- Terms for describing Application Profiles
-- Terms for describing DCMI terms (e.g., Status)
-- A controlled vocabulary of types of Status
-- The domains and ranges vocabulary

These vocabularies should use terms from RDF/RDFS when appropriate
but coin DCMI properties when necessary.

The way forward:

Stage 1

1. Approve the semantics of the classes [buy in,
public comment, f2f UB meeting, community consensus]
2. Approve the application of these classes as domains
and ranges for DCMI terms [buy in, public comment,
f2f UB meeting, community consensus]

Stage 2

3. Declare classes used as domains and ranges.
4. Declare DCMI properties (formally) using domains and ranges.

Stage 3

5. Consider implications for UB review of APs. This
may change the kinds of documentation we request
from communities -- e.g., with regard to refinement
of domains and ranges of properties in APs and
testing for compliance with DCMI domains and ranges.

AGREED: We want to start the process of the stages 1-3 above.

ACTION: Tom to deliver a work plan for how to achieve this.

NOTED: It was argued that clarification of how to implement
the agent elements is on the critical path to assigning
domains and ranges to DCMI properties.

NOTED: In a general sense, the revisions of DC-RDF and DC-XML
are addressing the above concern.

[1] http://dublincore.org/architecturewiki/DCPropertyDomainsRanges

----------------------------------------------------------------------
Agenda Item 5: Finalizing DCMI Type Vocabulary

Discussed "style" of the Type Vocabulary. Three styles of
definition considered [1]:

1. The style currently proposed for the DCMI Type Vocabulary [2]:
Collection: An aggregation of items.

2. DCMI Type style proposed during the comment period by Renaud [3]:
Collection: A resource which is an aggregation of items.

3. The style used by Andy in the draft Domain-Range Vocabulary [4]:
Collection: The class of all aggregations of items.

AGREED to style of DCMI Type Vocabulary, with no prefix (style number 1).

[1] http://dublincore.org/usage/meetings/2006/04/seattle/domains-ranges/
[2] http://stage.dublincore.org/usage/public-comment/2005/12/type-vocabulary-changes/
[3] http://stage.dublincore.org/usage/public-comment/2006/03/type-vocabulary-comments/
[4] http://dublincore.org/architecturewiki/DCPropertyDomainsRanges

COLLECTION
Definition: An aggregation of resources.

Justification for change: The original definition
referred to "an aggregation of items". However, we
would not want "item" to be understood in its "FRBR"
sense (this point will need to be elaborated in the
decision text).

Comment: A collection is described as a group; its parts
may also be separately described.

DATASET
Definition: Data encoded in a defined structure,

Comment: Examples include lists, tables, and databases.
A dataset may be useful for direct machine processing.

EVENT
Definition: A non-persistent, time-based occurrence.

IMAGE
Definition: A visual representation other than text.

MOVING IMAGE
Definition: A series of visual representations imparting
an impression of motion when shown in succession.

PHYSICAL OBJECT
Definition: An inanimate, three-dimensional object or substance.

SERVICE
Definition: A system that provides one or more functions.

SOFTWARE
Definition: A computer program in source or compiled form.

SOUND
Definition: A resource primarily intended to be heard.

STILL IMAGE
Definition: A static visual representation.

TEXT
Definition: A resource consisting primarily of words for reading.

INTERACTIVE RESOURCE
Definition: A resource requiring interaction from the user to be
understood, executed, or experienced.

ACTION 2006-04-30 (Tom and Stuart) Create an announcement text for DC
General and website [news] -- due 19 June
ACTION 2006-04-30 (Tom and Stuart) create a decision text and numbered
decision -- due 19 June
ACTION 2006-04-30 (Tom and Stuart) Finalize the above on the list
ACTION 2006-04-30 (Tom) Submit approved revisions to Directorate for
approval; after approval, rebuild and install Type
Vocabulary documentation

----------------------------------------------------------------------
Agenda Item 6 -- Review of Application Profiles

NOTE: Full notes for this agenda item have been moved to
http://dublincore.org/usage/minutes/html/2006-04-30.meeting-notes-dcap.html.
This section summarizes issues and actions only.

ISSUE: Local Definition: Definition is sacrosanct -- if you`re
using someone else`s properties the definition should not
be changed

ISSUE: Simple Dublin Core not requiring this example structure
(above): Simple DC defaults to describing resources -- so it
does not require different entities and models of entities.

ISSUE: Definition of an Application Profile
Rules by which you create a description set for an application?
The makeup of a description set?

AGREED: To wordsmith this definition of application profile:
`Rules by which a description set is "defined"`.

ISSUE: requirements for human reading and machine processing of APs

ISSUE: How do we maintain a master copy of this AP of an AP?
RDF/XML should be the master copy

AGREED: RDF/XML should be complete to generate XML.

ISSUE: Must serve properties from the property URI -- i.e.,
translations (Finnish) must come from DCMI namespaces

ISSUE: Do we need two specifications? One for humans
(documentational) and one for machines (formal)?

AGREED: A separate list of vocabulary encoding schemes can
be derived from Property Usage, so we do not need a separate
list as part of an application profile.

ISSUE: Is an application profile used for instance metadata
creation or instance metadata creation?

ISSUE: Do property usages have URI`s?

ISSUE: How do you say you must use LCSH? In Obligation?

ISSUE: Do we need "condition" or does it go in "best practices" documents?

ISSUES: Condition - RDF representation of the above

ACTION: TOM - formalize AP of APs, send back to UB.

Because of above AP of APs we need to:

ACITON: Evaluate the DCCD before Mexico -- SHEPERD: Andrew

ISSUE: Point people to a web page for Simple Dublin Core
need to be explicit about these properties and how they are
presented. Need to model Value String Usage and Obligation.

ISSUE: RDF representation of above

NOTE: "Usage in this DCAP" is something like "Usage Comments"

DISCUSSION: What is Simple Dublin Core?

-- "Simple DC" is a concept used in a number of ways in a
number of places. Do we address it in reference to OAI?

-- "Simple DC is a description set with one description that
describes a resource with 15 optional property usages"

-- If we say Simple DC is a conforming AP, then folks will
be using it as a model.

-- Why do we need an AP to say what Simple DC is? Because you
have to say the 15 properties are optional and repeatable.

-- What goes on a AP for Simple DC? It should include those
properties of the DCMI Profile Model (Application Profile
of Application Profiles).

ACTION: Tom write an AP of Simple DC according to the new
and incomplete AP of APs -- see above -- (e.g., adding
occurrence, obligation, etc.)

-- ISSUE: OAI uses value string language. Do we put anything
about value string language in this AP?

-- AGREED: Simple DC includes value string language, and this
is optional.

-- AGREED: Need to include URI in Simple DC AP, not the QName.

-- AGREED: Do not cite our own XML schemas in the AP for Simple DC

-- ISSUE: Documentation mentioning "Simple Dublin Core" should be
revised to point to the Simple DC AP.

----------------------------------------------------------------------
Agenda Item 7 -- Documentation Roadmap

ISSUE: The purpose of DC is resource description -- state what that means.

ISSUE: Point 1.3.2. Kernel -- why have a minimal set?

AGREED: Total lack of enthusiasm for point 1.3.2

AGREED: 1.4.2. should be renamed to "How to declare a set of metadata terms"

ISSUE: Include Glossary and other legacy documents in Roadmap:
Bibliography
Usage Guide -- What role does the document "Using Dublin
Core" play in a world of APs?
Glossary

If they are not included in roadmap for documentation we have
to explicit about what is happening to these key documents
[Bibliography, Usage Guide, Glossary].

How do we provide documentation that continues to meet
the needs of people who are not yet operating under
APs, as we try to meet the needs of folks using APs?
We want to think about the pieces that will support
this transition.

ISSUE: URIs attached to modeling components in DCAM?

ISSUE: Define terms in one place and cite them in other documents.

ISSUE: When writing a document about DCAM, we should be able
to cite a Glossary, not the DCAM -- you don't want versioning
of DCAM because of this.

Look to document management discourse to help us solve
this term definition problem.

QUESTIONS about glossary:
Do we want to maintain a glossary that is wide in scope?
Do we want to maintain terminology that DCMI uses --
i.e., more focused in scope?

AGREED we need some sort of glossary or terminology
list, more tightly focused on DCMI terminology.

----------------------------------------------------------------------
Wikipedia

Is this a UB issue? Is the Wikipedia article a DCMI document?
It should be on the DCMI documentation roadmap.

AGREED: The Wikipedia article is a documentation issue and
Tom can involve people as needed.

Looks like you have to subscribe to a Wikipedia page to learn
about updates to it. Issue: what is our brand?

Use deliverable from Barbara to discuss the DCMI
brand Trustees, Advisory Board, Usage Board.

----------------------------------------------------------------------
RDA

Why are we talking about RDA? DC Libraries Working Group
was asked to suggest a liaison to ALA committee that is
trying to participate in RDA [replacement for AACR2].
They came to DC because there was an interest in being a
content standard for more than just MARC (DC, VRA, etc.) --
to broaden its use. They want to make it relevant outside
the traditional cataloguing arena. Diane said she'd be part
of this. There may be value in assembling some DC content
recommendations in one place (e.g., how to construct a name
in a description).

----------------------------------------------------------------------
Alternative Paths to Semantic Specificity [not best handle for discussion]

Decision Tree - this is good when things are clear, but
perhaps not when things are unclear. When do you define
multiple properties and when do you define a single property
with multiple encoding schemes? AND is this something about
which the UB can make a decision on?

AGREED: UB should make a statement about this. Where would
this be stated? In Application Profiles. This relates to
best practices for creating good descriptions.

ISSUE: We may not be in conformance with our own decision
on this. This needs to be addressed in a concrete way.
The word "or" is a problem. Therefore defining domains and
ranges is very important.

There is also a measure of closeness -- in properties to
resources. This should be done in Guidelines to Creating
Application Profiles.

CAPTURED: In defining a range to a proposed property if the
word "or" comes up you potentially have a problem. How many
words different in the proposed definition? How similar
are the semantics of the resource to the vocabulary encoding
schemes?

----------------------------------------------------------------------
UB Process Issues

Two things resting there, but they are not critical.
How do we process changes to our own process?

Why are we changing wording in UB Process: Voting -- because
bylaws do not have a presence requirement. This issue on
presence in voting can cut both ways.

AGREED: Affirm the culture of conversation and consensus.

Delete second full sentence of revised 5.7. Change last
sentence to say: may explore their voting options.

ACTION: Stuart revise this text.

Voted:
7 agreed to change this
0 did not want to change this
0 abstained
[100% UB present]

ADD TO AGENDA: we need a piece on the process of the UB doing
its process document - we need to review new section 10 on
Usage Board processes for changing their processes.

ACTION: Stuart will circulate this text.

2009-01-29: Changed usageboard/log URIs to usage/minutes URIs.