Usage Board 2006-04-29
Seattle

Agenda Item 1: Changes to Terms in the DCMI Namespace

(a)
Three texts: (1) announcement text, [two paragraph] (2) decision text [longer and detailed], and (3) introduction to public comment document

Agreed: that text on page 10, draft announcement text, be expanded into a longer decision text that describes the types of changes being proposed

Announcement Text
Decision Text 
Shorter version of 2, i.e., an Introduction to Public Comment Document

For each of the problem statements cite the problems listed in the introduction. 

Action: Tom to supply outline of these changes 

(b)
Distinction between:
	Intellectual content of the resource
	Content of the resource
	
	= non-issue

Distinction between:
Content of the resource
Resource

	= Resource is broader than content of resource

Points – 
people have already used a more generalized definition because they’re describing resources that are not document-like content objects
our experience indicates that this is a problem for people who are trying to apply these definitions
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
this will bring definitions in line with practice

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


(c)
Point-by-point analysis

(c.1) 
COVERAGE – break last sentence of proposed comment into two, because as it stands it’s awkward

Change proposed comment in COVERAGE to:
“recommended best practice is to use a controlled vocabulary such as…”

ACTION: Andrew

(c.2)
DESCRIPTION

Description – in the problem statement in first sentence point back to content resource statement [apply consistently throughout], “see discussion above…”

(c.3)
FORMAT

 – dimension vs. extent 

@@TODO FLAGGED – question for further discussion

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: proposed definition of FORMAT should be: “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 don’t think that we’ve 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, instead of [or something like this written].

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.

(c.4)
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.


(c.5)
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.”

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

(c.6)
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.”

(c.7)
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.”


(c.8)
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.”

(c.9)
TYPE

Take “for example” out of parenthetical

Comment:
Instead of “select a value” use “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.

(c.10)
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

(a)
Diane – 

(c.1)
URI

delete second slash in RFC 39 in both references

(c.2)
ALTERNATIVE TITLE
potential problem with comment to alternative title – it seems odd, but not necessarily wrong

it seems like it’s 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?

Where did come from? – to allow a distinction between primary and secondary titles. (the secondary title is there for access purposes).

ACTION: Tom go through the DCTERMS to normalize according to guidelines

AGREED: change comment for ALTERNATIVE TITLE

Can we get rid of ALTERNATIVE TITLE?

Proposed definition:
An alternative name for the resource

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

(c.3)
EDUCATION LEVEL

2 issues – 
AUDIENCE – is defined as a class of entity for whom the resource is intended
EDUCATION LEVEL is a refinement of audience – therefore its definition is broken
definition of education level needs fixing

Is EDUCATION LEVEL a refinement of AUDIENCE?

AGREED: yes, EDUCATION LEVEL is a refinement of AUDIENCE

Need to change the definition of Education Level.

AUDIENCE: 
AGREED: this is the definition for EDUCATION LEVEL:
An audience, defined in terms of its progression through an educational or training context, for whom the resource is intended.

(c.4)

Agenda Item #3: Replicating DCMES in the DCTERMS Namespace

Communities need to be convinced that this is a good idea

Need to have data from implementers on impact
	Commercial (Adobe, etc.)
	Aggregators (NSDL, etc.)
	
We should not rush this decision.

STRAW POLL: a majority of the UB members recommend that DCMI replicate the 15 elements in the DCTERMS namespace

Do we need one namespace for all DCMI properties?

VOTED: Do we need one namespace for all DCMI properties:
Yes = 6
No = 1
Abstain = 0
[100% of the UB was present]

ACTION: Makx and Tom need to look at timeline, priorities, and how to do impact analysis and what the resource requirements 


Agenda Item #4: DCMI Property Domains and Ranges

Do we want to assign domains and ranges to DC properties?
Advantages: (1) semantics of the DC properties much more specific and explicit (2) support inferencing in the semantic web

Disadvantages: 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:
DCMI classes from scratch?  Create DCMI classes from extant classes, adding where necessary.

Work to date has created 33 new classes (new terms in the domains and ranges vocabulary)

What do extant classes look like?

If we decide to do (1) above, we don’t have to do work to support (2), except through documentation.  That is, we may not need to create new URIs.

DCAM vocab.
AP Documents vocab.
DCMI TERMS vocab. 
Status vocab.
Domains and Ranges vocab.

These vocabs should be composed of terms from RDF/RDFS and DCMI. Is this composite vocab an AP?

Decision process for this agenda item:
We need to:
Stage 1:
Approve the semantics of the classes [buy in, public comment, f2f UB meeting, community consensus]
Approve that the application of these semantics of these properties in domains and ranges [buy in, public comment, f2f UB meeting, community consensus]
Stage 2:
Declare classes used as domains and ranges
Declare DCMI properties (formally) using domains and ranges
Stage 3:
Consider implications for UB review of APs [this may change the kinds of documentation we request from communities, it may refine domains and ranges of properties in APs, testing for compliance with DCMI domains and ranges]

What are stable namespaces we could reuse for this?

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

ACTION: Tom – find a way to proceed with this agenda item (deliver a work plan)

Diane is arguing that clarification of how to implement the agent elements is on the critical path to assigning domains and ranges to DCMI properties.

In a general sense – the revisions of DC in RDF and DC in XML are addressing the above concern.



Agenda Item #5: Finalizing DCMI Type Vocabulary

Style of Type Vocabulary – 

Three styles of definition:
	No prefix
	Resource [Renaud]
	Class [based on Domain and Range work]

AGREED: that the style of the DCMI Type has no prefix [style number 1, style that we currently use]

(a.1)
COLLECTION – definition: an aggregation of resources

Justification for change – we don’t want to confuse item here, with item in FRBR.

COLLECTION – comment: a collection is described as a group; its parts may also be separately described.

(a.2)
DATASET – definition: Data encoded in a defined structure, 

DATASET – comment: Examples include lists, tables, and databases.  A dataset is intended to be useful….

(a.3)
EVENT –  we like our language

(a.4)
IMAGE – definition: A visual representation other than text.

(a.5). 
MOVING IMAGE – definition: A series of visual ? [representation], when shown in succession, impart an impression of motion.

(a.6)
PHYSICAL ARTIFACTS – definition: An inanimate, three-dimensional object or substance.

(a.7)
SERVICE – definition: A system that provides one or more functions.

(a.8)
SOFTWARE – definition: A computer program in source or compiled form. 

(a.9)
SOUND – definition:  a problem [Auditory material.]

(a.10)
STILL IMAGE – definition: A static visual representation.

(a.11)
TEXT – definition: Words for reading.






DAY TWO: 
2006-04-30
Seattle

IMPORTED FROM TOM:

Collection.      An aggregation of resources.
                Comment:  A collection is described as a group; its parts may also be 
                 separately described.

Dataset.         Data encoded in a defined structure. 
                Comment: Examples include lists, tables, and databases.  A dataset may be useful 
for direct machine processing.

Event.           A non-persistent, time-based occurrence.

Image.           A visual representation other than text.

Interactive Resource.	A resource requiring interaction from the user to be 
understood, executed,  or experienced.  

Moving image.    A series of visual representations imparting an impression of motion when 
shown in succession.

Physical Object. An inanimate, three-dimensional object or substance.

Service.         A system providing one or more functions.

Software.        A computer program in source or compiled form. 

Sound.           A resource primarily intended to be heard.

Still image.     A static visual representation.

Text.            A resource consisting primarily of words for reading.



VOTED: Moving Image definition
6 = approved the definition
1= did not approve the definition
0=abstained
[100% Usage Board present]

ACTION: Tom and Stuart - create an announcement text for DC General and website [news] – due 19 June
ACTION: Tom and Stuart - create a decision text and numbered decision – due 19 June
ACTION: Tom and Stuart - both of those need to finalized on the list – due 19 June
ACTION: Tom – submit to Directorate, then to and after approval to rebuild the Type Vocabulary documentation – due 19 June

Discussion
[Short discussion of Registry work – Diane and John Phipps]




Agenda Item #6 – Review of Application Profiles

How can we make it easy for users to prepare application profiles?

These are extant documents that relate to application profiles:

Basic:
	DCAP (CEN) documentation guidelines
	Term Decision Tree
	DCAP-in-RDF (CEN)
	DCMI Abstract Model -> DCAP Model?

Examples
	Simple DC
	Collection Description Summary
	Collection Description
	“UB application profile”
	Libraries application profile

What is a DCAP?
	
What is an application profile?
OLD – list of terms


NEW - Statement of what set of things are being described, and a list of terms that going to be used to describe those things. – If this is agreed we need an application profile application profile.

Application Profile
	Description of Application
	Model of entities (e.g., entity-relationship model)
		[class of entity being described]
Property Usage
		Uses Property -> [term URI] – for additional DCMI properties
		Local Label – Source Label
Local Definition – Source Definition [Usage in the DCAP]
		Local Comments – Source Comments [Usage in the DCAP]
		SubPropertyOf – Source SubPropertyOf
		InEncodingScheme – Qualified usage for encoding scheme
dcmi: Obligation
			Condition
			Datatype
			Occurence
		QualifiedNameforProperty
		[checklist for components of DCAM]
			ValueURI – whether  need
			Value String
			Rich representation
			Qualified Name for Syntax Encoding Scheme


Example structure:

Description
	- Model
Model of Entity 2
	Property 1
	Property 2
	Property 3
Model of Entity 2
	Property 1
	Property 2
	Property 3

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


Is this what we’re doing?:

Description of DCAP
Model 
Description Set
	Description 1
		Property Usage
		PU
	Description 2
		PU
		PU

What would an application profile of an application profile look like?


An abbreviated example of a DCAP 
	dc:title = Simple DC
	dc:description = description of what Simple DC here
	Description Set
		Description
			Occurrence = 1
			Class entities this describes = Resource
			Property Usage
				Uses property = dc:title
				…
				…
			Property Usage
				….
				…

Another abbreviated example of a DCAP
	dc:title = DCCD
	Description Set
		Description
			Occurrence = 1
			Class of entities = collection
			…
		Description
			Occurrence = 1 or more
			Class of entities = agent
			…

MOVING TOWARD AN OUTLINE of an Application Profile for an Application Profile:

Description of this DCAP
	dc:creator = Tom Baker
	dc:title=myApplicationProfile
	dc:description=….
	… [expand on this]
Description Usage
	Class of described resources = collection 
	Occurrence = 1 or more, 1… etc.
	Property Usages
		Class of described resources = collection 
		Occurrence = 1 or more, 1… etc.
	Property Usages
		…
	Property Usages
		…
Description Usage
	Class of described resources = ??? 
	Occurrence = 1 or more, 1… etc.
	Property Usages
		…

[this should all conform to the abstract model]


ISSUE: How do we maintain a master copy of this AP of an AP?

RDF/XML should be the master copy 


NSDL Interface -> RDF/XML -> HTML or XML
OR
Dctext -> RDF/XML-> HTML or XML
OR 
Schema Generation Tool -> RDF/XML-> HTML or XML
OR 
Human -> RDF/XML-> HTML or XML


AGREED: RDF/XML should be complete to generate XML


TOWARD A COMPLETE APPLICATION PROFILE OF AN APPLICATION PROfile:

Uses Property
Label for this DCAP
Usage in this DCAP
Source Label {for information only} [do these by reference]
Source Definition {for information only} [do these by reference]
Source Comment {for information only} [do these by reference]
[take out local definition]
[take out local comments]

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)?


DOCUMENTATIONAL READABLE
Property Usage Uses Property
Label for this DCAP
Usage in this DCAP
Source Label {for information only} [do these by reference]
Source Definition {for information only} [do these by reference]
Source Comment {for information only} [do these by reference]
[Constraints]
		Obligation
		Occurrence
		Condition [text]

FORMAL READABLE [incomplete and draft]
Property Usage
Uses Property
Label for this DCAP
Usage in this DCAP
[Constraints]
		Obligation
			Value String Usage
Value URI Usage
Rich Representation Usage
		Occurrence
			Value String Usage
Value URI Usage
Rich Representation Usage
		Condition [text] {flagged for further discussion}
Value String Usage?
[Constraints]
		Obligation
			Value String Usage
Value URI Usage
Rich Representation Usage
		Occurrence
			Value String Usage
Value URI Usage
Rich Representation Usage
		Condition [text] {flagged for further discussion}
Value URI Usage?
Syntax Encoding Scheme Usage?
Rich Representation Usage?
Vocabulary Encoding Scheme Usage
[Constraints]
		Obligation
			Value String Usage
Value URI Usage
Syntax Encoding Scheme Usage
Rich Representation Usage
		Occurrence
			Value String Usage
Value URI Usage
Syntax Encoding Scheme Usage
Rich Representation Usage
Condition [text] {flagged for further discussion}
		Used Vocabulary Encoding Scheme
		Label for this in DCAP
		Usage in this DCAP
		Syntax Encoding Scheme [Usage]?
	

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?

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: What is Simple Dublin Core really?

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. 

Schema is a way of writing down an AP.  

What goes on a AP for Simple DC?  It should include those properties of the AP of the APs.  

ACTION: Tom write an AP of Simple DC according to the new and incomplete AP of APs (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: everything should point to the Simple DC AP.


Agenda Item #7 – Documentation Roadmap

ISSUES: the purpose of DC is resource description, state what that means

ISSUES: 1.3.2. Kernel – why have a minimal set? 

AGREED: Total lack of enthusiasm for 1.3.2

1.4.2. should be “How to declare a set of metadata terms”

ISSUE: Glossary and other legacy documents [Usage Guide and Bibliography]

ISSUE: URI’s attached to modeling components in DCAM?

Key documents not in roadmap:
Bibliography
Usage Guide
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].

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.

Question: do we want to maintain a glossary – wide in scope?
Question: do we want to maintain terminology that DCMI uses – more focused in scope?


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

What role does the document “Using Dublin Core” play in a world of APs?

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.


Back Burner: Wikipedia, RDA, Semantic Specificity, UB Process Issues

(bb.1)
Wikipedia

Is this a UB issue?

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

AGREED: it 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.


(bb.2)
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 of DC’s content recommendations in one place (e.g., how to construct a name in a description).

(bb.3)
Alternative Paths to Semantic Specificity [not best handle for discussion]

Decision Tree
	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?




(bb.4)
UB Process Issues

Two things resting there, but they’re 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