Title: DCMI Usage Board Meeting, 29-30 April 2006, Seattle Identifier: http://dublincore.org/usage/minutes/2006/2006-04-30.meeting-notes-final.html Source: 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/2006/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.