DCMI Usage Board:
One-stop worksheet of issues and links
Thomas Baker (thomas.baker@bi.fhg.de)
Version: Fri May 3 17:15:01 EDT 2002
UB Web pages I maintain at http://www.gmd.de/People/Thomas.Baker
UB Web pages I maintain at http://dublincore.org/usage
UB documentation
DC-General and working groups
DCMI Metadata Terms
UB-related Web pages to monitor
Issues related to the registry
Issues related to encoding schemes
Issues related to naming
Issues for the Web team
Issues of process and Usage Board role/jurisdiction
DCSV - Structured values
Other
------------------------------------------------------------------------------
UB Web pages I maintain at http://www.gmd.de/People/Thomas.Baker
------------------------------------------------------------------------------
1) Issues and links (this page): [issues.txt]
Source: file://localhost/e:/u/folders/_usage/issues.txt
HTML: file://localhost/e:/u/folders/_usage/_html/issues.html
Recent version at: http://www.gmd.de/People/Thomas.Baker/issues.html
2) DCMI Usage Board meeting agenda [for upcoming meeting] [agenda.txt]
Source: file://localhost/e:/u/folders/_usage/agenda.txt
HTML: file://localhost/e:/u/folders/_usage/_html/agenda.html
Available from: http://dublincore.org/usage/meetings/index.shtml
Available from: http://www.gmd.de/People/Thomas.Baker/agenda.html
On completion of a meeting, the file will be frozen and archived as
http://dublincore.org/usage/meetings/2002/05/agenda.html (for example)
and linked to http://dublincore.org/usage/meetings/.
------------------------------------------------------------------------------
UB Web pages I maintain at http://dublincore.org/usage/
------------------------------------------------------------------------------
1) DCMI Usage Board documentation [index-documents.txt]
Source: file://localhost/e:/u/folders/_usage/index-documents.txt
HTML: file://localhost/e:/u/folders/_usage/_html/index-documents.shtml
Installed as: http://dublincore.org/usage/documents/index.shtml
2) DCMI Usage Board Meetings - a chronology [index-meetings.txt]
Source: file://localhost/e:/u/folders/_usage/index-meetings.txt
HTML: file://localhost/e:/u/folders/_usage/_html/index-meetings.shtml
Installed as: http://dublincore.org/usage/meetings/index.shtml
3) DCMI Usage Board decisions [index-decisions.txt]
Source: file://localhost/e:/u/folders/_usage/index-decisions.txt
HTML: file://localhost/e:/u/folders/_usage/_html/index-decisions.shtml
Installed as: http://dublincore.org/usage/decisions/index.shtml
Example: http://dublincore.org/usage/decisions/index.shtml#2001.01
4) DCMI Metadata Terms - an Overview [index-terms.txt]
Source: file://localhost/e:/u/folders/_usage/index-terms.txt
HTML: file://localhost/e:/u/folders/_usage/_html/index-terms.html
Installed as: http://dublincore.org/usage/terms/index.shtml
5) DCMI Elements and Qualifiers [index-elements-qualifiers.txt]
Source: file://localhost/e:/u/folders/_usage/index-elements-qualifiers.txt
HTML: file://localhost/e:/u/folders/_usage/_html/index-elements-qualifiers.html
Installed as: http://dublincore.org/usage/terms/elements-qualifiers/index.shtml
Archived at: http://dublincore.org/usage/terms/2002/04/22/elements-qualifiers/
------------------------------------------------------------------------------
DC-General and working groups
------------------------------------------------------------------------------
http://dublincore.org/groups/architecture/
http://dublincore.org/groups/languages/
http://dublincore.org/groups/registry/
http://dublincore.org/usage/
http://www.jiscmail.ac.uk/lists/dc-architecture.html
http://www.jiscmail.ac.uk/lists/dc-general.html
http://www.jiscmail.ac.uk/lists/dc-international.html
http://www.jiscmail.ac.uk/lists/dc-registry.html
http://www.jiscmail.ac.uk/lists/dc-usage.html
------------------------------------------------------------------------------
http://dublincore.org/usage/terms/elements-qualifiers/
------------------------------------------------------------------------------
== Several of the documents on the DCMI Recommendations page
at http://dublincore.org/documents/#recommendations describe
"semantics" and, as such, are now under the jurisdiction
of the Usage Board. These should be moved or linked to
http://dublincore.org/usage/. These are:
http://dublincore.org/documents/2000/07/11/dcmi-type-vocabulary/
http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/
http://dublincore.org/documents/1999/07/02/dces/
http://dublincore.org/documents/1998/09/dces/
http://www.ietf.org/rfc/rfc2413.txt
== What about:
http://dublincore.org/documents/dcmes-qualifiers/ (a redirect)
http://dublincore.org/documents/dces/ (a redirect)
http://dublincore.org/resources/translations/
http://dublincore.org/qdcmes/1.0/
-- Database attributes: Does the attribute set presented in
http://dublincore.org/usage/terms/elements-qualifiers/ capture
the information we will need to record about metadata terms
in the Vocabulary Management System? Is the implicit
attribute set in decisions.html appropriate and adequate?
-- References (footnotes) embedded in term definitions: Note
that http://dublincore.org/usage/terms/elements-qualifiers/
has a "references cited" section, following the
recommendation Web page for DCMES 1.1. As we move towards a
database environment do we need to make element definitions
more "self-contained" by including all such citations in
individual term definitions?
-- The case of term names: Andy has argued that we should
uniformly put "name" tokens into lowercase to follow emerging
practice in XML and RDF communities. User guides could
recommend that applications tolerate mixed-case term names
for legacy reasons. If we are going to do this, there is no
better time than now. (In this case, a sentence of
explanation would need to be added to the Introduction of
http://dublincore.org/usage/terms/elements-qualifiers/.)
-- If Andy and Pete's XML guidelines are now in line with the
RDF style of tagging -- the flat {dcterms:alternative}{/...}
as opposed to the nested
{dc:title}{dcterms:alternative}{/...}{/...} -- then our
grammar will need to be reworded accordingly. Anticipating
the desirability of doing this, I have tried to describe DCMI
grammar in the overview terms.html page in a way that does
not preclude this.
-- Do we want to give the
http://dublincore.org/usage/terms/elements-qualifiers/
document a catchy name, such as "DCMI Dictionary"??
------------------------------------------------------------------------------
UB-related Web pages to monitor
------------------------------------------------------------------------------
== http://dublincore.org/documents/2001/04/12/usageguide/glossary.shtml (Apr 2002)
Definitions of things like "DC-Simple", discussed on the dc-architecture
list in April 2002.
== http://dublincore.org/documents/usageguide/
Diane's "Using Dublin Core" - version was 2001-04-12 as of 2002-04-18
== http://dublincore.org/resources/faq/
Questions dealing with Simple versus Qualified Dublin
Core, Dumb-Down Principle, etc.
== Usage Board should be described here:
http://dublincore.org/about/
http://dublincore.org/about/organization/
http://dublincore.org/resources/
http://dublincore.org/resources/faq
== Usage Board in the news...
http://dublincore.org/news/communications/ - DCMI Update
== Documents available for public comment
http://dublincore.org/news/communications/public-comment.shtml
http://dublincore.org/groups/usage/public-comment.shtml
== http://dublincore.org/documents/dcq-rdf-xml/
http://dublincore.org/documents/dcmes-xml/
http://www.ukoln.ac.uk/metadata/resources/dc/dc-xml-guidelines/
------------------------------------------------------------------------------
Issues related to the registry
------------------------------------------------------------------------------
http://wip.dublincore.org:8080/registry/Registry - three prototypes (Apr 2002)
http://www.jiscmail.ac.uk/lists/dc-registry.html
http://dublincore.org/groups/registry/
http://dublincore.org/groups/registry/VMT-Registry-Roadmap-v1.2.ppt
http://dublincore.org/groups/registry/DCMI-reg-roadmapv4.html (Feb 18 2002)
http://wip.dublincore.org:8080/schemes/index.html
-- Vocabulary and Encoding Scheme Registration (prototype)
== DCMI Roadmap for development of Vocabulary Management and
Schema Registry Systems, version Feb 18 2002 (as of Apr 18), at
http://dublincore.org/groups/registry/DCMI-reg-roadmapv4.html:
"sections 3 and 4 await comment from Usage Board".
== Registry requirements: link from terms to UB decisions?
== Eric Miller prototype
http://www.w3.org/2001/10/navigate/ - successor to potlach.org (Nov 02 2001)
------------------------------------------------------------------------------
Issues related to encoding schemes
------------------------------------------------------------------------------
== Candidates for approval:
http://www.lub.lu.se/~traugott/drafts/DC-Vocabulary-Qualifiers.html
(Apr 2002)
== Guidelines,
http://www.lub.lu.se/~traugott/drafts/vocab-guide3.html
(Mar 2002) must go onto Web at
http://dublincore.org/usage/documents/vocabulary-guidelines/
(Apr 18 2002)
== Vocabulary and Encoding Scheme Registration (prototype)
http://wip.dublincore.org:8080/schemes/index.html (Apr 2002)
== Is Unicode needed? User interface in several languages?
(Traugott, Mar 2002)
== Make all subject vocabulary qualifiers available from DCMI
Registry? (Traugott, Mar 2002)
== "Do all the vocabularies need to be represented in an RDF
schema eg for validation purposes?" (Traugott, Mar 2002)
== Should the five "recommended" subject schemes (DDC, UCD,
LCC, LCSH, MeSH) voted in to the terms namespace remain
there? (Traugott, Mar 2002)
== Should DCMI register encoding schemes for Identifier, or
force people to register schemes externally to DCMI, either
as new URI schemes or as URN NIDs or both? URI, DOI, IDBN,
ISSN, SICI, and OpenURL have been proposed at various times
(Andy, Sep 17 2001). ISSN and ISBN have been formally
registered as URN Namespaces
http://www.iana.org/assignments/urn-namespaces. That is
they are already covered by URI - no further action will be
needed on our side other than to point this out to working
groups. (Roland, Dec 2001)
== Distinguish between cross-domain and domain-specific for Type
and Subject encoding schemes?
== How should DCMI register encoding schemes for elements other than
Subject -- via Web form or via formal UB review?
== Encoding scheme "URI" for Description and Rights (Rebecca,
Oct 12 2001)
== Articulate guidelines on using URIs as values, for example:
In Identifier, Relation and Source, the use of 'URI' as an
encoding scheme means "here is the value and it is a URI".
In Rights and Description, the use of 'URI' as an encoding
scheme would mean "the value can be found at the following
URI". These two things are not the same and therefore
shouldn't be encoded using the same mechanism. (Andy, Oct
14 2001)
== Who can register an encoding scheme for their subject
vocabulary? Anyone ("my vocabulary")? A project? Or only
"publicly recognized schemas"? Some sentiment towards tight
requirements on maintenance bodies. (Stuart, Diane, Roland,
Dec 09 2001)
== Do we need to document registrations of encoding schemes as
"decisions" in a way analogous to term proposals (assign
numbers, Web pages, etc)? Probably not. (Stuart, Dec 12 2001)
== Registration of schemes for Type.
== Should all encoding schemes for Identifier hold also for
Relation and Source? Do we need to capture this in our
documentation?
== Backlog of subject encoding scheme proposals: SWB (Berthold
Weiss), mathematical subject headings (Hans Becker)
------------------------------------------------------------------------------
Issues related to naming
------------------------------------------------------------------------------
== "Adjective-like" versus "stand-alone" names for element
refinements. There seems to be a consensus that names should
now be "stand-alone" (eg, "alternativeTitle" versus just
"Alternative"). Do we need to capture this in our
documentation? And if we henceforth follow this style, what
to do with the legacy recommended qualifiers Alternative,
Created, Valid, Available, Issued, Modified, Spatial, and
Temporal? (see Andy posting, June 2001)
== If we agree henceforth use only stand-alone names, then we have
following options:
1) We leave dcq:alternative alone (along with Created, Valid,
Available, Issued, Modified, Spatial, and Temporal) and switch
to using stand-alone names in the future.
2) We change their names in both the Recommendation document and
in the RDF schema thereof.
3) We create a redundant set of names (e.g., dcq:alternativeTitle)
with equivalency relationships to the existing names.
Andy -- doubts if option 2) is possible.
-- likes 3) but doesn't know if it is technically possible - investigate?
-- could live with 1) though I don't think it is ideal.
Diane: option 1 is the most practical.
Andy: should we see
meta name="DCQ.created" scheme="W3CDTF" content="2001-06-15"
in HTML meta tags?
== Case of element names 'title' vs. 'Title' (Andy, Jan 2002)
------------------------------------------------------------------------------
Issues for the Web team
------------------------------------------------------------------------------
== We see a requirement to be able to annotate specific
documents with time-stamped comments -- instead of reissuing
a document with "errata" attached, simply annotate?
== For Web Team: we need a simple Web form to submit edited
documents.
== Perhaps there needs to be a "see also" reference from the term
declaration to the Usage Guide and to documentation prepared by
working groups in support of the terms at the proposal stage.
------------------------------------------------------------------------------
Issues of process and Usage Board role/jurisdiction
------------------------------------------------------------------------------
== Need two extra weeks before one-month comment period in order to
get stuff up on Web, etc.!!!
== http://128.253.121.110/DC-UB/DC-UBprocess8.html not yet
posted on Web site.
== DCMI has indicated an intention to get into namespace
hosting; said to be out of scope for UB. To what extent are
the policies governing NSes outside the UB jurisdiction
(naming, persistence, quality control)? (Apr 2002)
== Potential role of UB in oversight of schemas (RDF and XML
encodings) used in the DCMI registry or published on the Web
for use in Semantic Web applications.
== In approving new term proposals, what weight should UB give
to working-group process, buy-in, and proven implementation
experience. To what extent is UB in job of a
priori/posteriori. How strict? If nobody complains, is
that sufficient proof to the UB that there are no adverse
effects?
== On whose judgement and with whose approval can the UB revise
and evolve its own process? Currently, there is a
placeholder in the process document (Stuart Dec 12 2001)
------------------------------------------------------------------------------
DCSV - Structured values
------------------------------------------------------------------------------
http://www.mailbase.ac.uk/lists/dc-ac/2000-08/0018.html
http://www.mailbase.ac.uk/lists/dc-ac/2000-08/0025.html
http://dublincore.org/documents/2000/07/28/dcmi-dcsv/
http://dublincore.org/documents/labelled-values-syntax/
http://dublincore.org/documents/dcmi-point/
http://dublincore.org/documents/dcmi-period/
http://dublincore.org/documents/dcmi-box/
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0204&L=dc-usage&O=A&P=2547 (Andy)
== The status of the DCSV "recommendation" itself needs to
be clarified. It was never voted on as an approved encoding
scheme and is not part of the dcterms namespace; rather, it
was "silently" (and at the time controversially) given
"recommended" status in circa August 2000 by the Directorate
on the grounds that its recommendation was implied by our
approval DCMI Point, Box, and Period.
------------------------------------------------------------------------------
Other
------------------------------------------------------------------------------
== Definition of "title" should be reworded to eliminate an
inherent assumption that a resource must have a
well-defined, unique, formal title. (Roland, Oct 2 2001)
== CEN/CWA is defining a mapping between DC and ISO 19115. Do
we need to look at this?
== As proposed in 1999, the Format qualifier "medium" is only
applicable to physical resources and "IMT" is only applicable
to virtual resources. Do we need to revise the official
definitions? (Andy, Feb 25 2002)
== RDDL in effect defines its own core element set for resource
discovery -- one that overlaps in awkward ways with Dublin
Core. See http://www.openhealth.org/RDDL/ and
http://www.openhealth.org/RDDL/rddl.rdfs
== Is it acceptable to use DC metadata to describe non-DLOs
(such as people, organisations, museum artefacts, events,
hurricanes, species)? Or: does DCMI want to say that it is
*not* acceptable to describe these kinds of things using DC
metadata? If not, do we need to indicate somehwere that the
current DCMI Type list is _not_ intended to be an exhaustive
list of the kinds of resources that DC can be used to
describe? (Andy, Jan 2002)
== To what extent is the current list of types in the DCMIType
list an exhaustive list of the kinds of resources that can
be described using DC metadata? (Andy, Jan 2002)
== If it is acceptable to describe non-DLOs using DC metadata,
does DCMI want to provide any best-practice guidelines for
how to do it in specific instances, such as for people? If
so, what DCMI WGs would do this? (Andy, Jan 2002)
== 2002-04-24: Andrew Wilson circulated, with John Roberts,
a paper on records management/recordkeeping metadata.
file://localhost/e:/u/attach/2002-04-24.DCMIResourceManagement-final.doc
== 2002-04-24 Deane Zeeman, deane.zeeman@nlc-bnc.ca
The Treasury Board Secretariat Canada Interdepartmental Metadata
Working Group (the body directing and coordinating metadata
efforts in the Govt. of Canada) is assuming - always a
dangerous practice - that scheme registration will be
de-centralized; that we will be able to register schemes in our
domain and count on DCMI to register schemes with broader
coverage = (e.g. LCSH, DDC, etc). We are hoping that DCMI
would refuse to register schemes in our domain and refer such
attempts to our registry. Is this decentralized model in line
with Usage Board thinking on the subject? Is it likely that
such an issue would be discussing at the upcoming Usage Board
meeting at UKOLN? I'd appreciate your take on this issue. I
would certainly also appreciate any comments/suggestions you
might have regarding the attachment.
e:/u/attach/2002-04-24.Canada.registration_process.doc
== Should DCMI use the term 'application profile' to describe
sub-sets of its vocabulary? Arguments "contra": An application
profile 'uses' standard terms in an optimised way for a
particular application; there are an infinite variety of
application profiles that could be constructed. DCMI has said
it is not in the business of 'approving' an unlimited number of
application profiles DCMI recommendations needs to advise on
'generic' use of DCMI terms. Should we 'approve' particular
application profiles which may well emerge in a fairly arbitrary
way? How will DCMI distinguish between application profiles it
wants to consider in the approval process and those it does
not??
Andy on identifiers, Jan 2002
I don't think there was any follow-up to my last posting
on this subject? In any case, I've tried to write up
some guidelines about encoding various commonly used
identifiers as URIs in DC metadata. This issue pops up
on the lists every now ang again, so it would be good to
have something to refer to. See
http://www.ukoln.ac.uk/metadata/dcmi/dc-identifiers/
for my first draft. I'd like to send this to
dc-architecture for comment - does that sound
reasonable? Would anyone on this list like to disagree
with my recommendations?
------------------------------------------------------------
New Web pages
------------------------------------------------------------
CHANGE REFERENCE TO DCT1 to dcmi-type-vocabulary!!!
Rachel:
In particular, it is on the agenda in Bath to clarify whether
a database of "decision" events is a good way to structure
things. Perhaps the addition of a "decision" link to a term
description could trigger a change of internal version of an
individual term within the VMS. Instead of linking all of the
supporting documentation for individual decisions directly to
the term database, the decision database would be the thing
that pulls together all supporting documentation and meeting
notes that contextualize a change. In the term database,
then, a new version of the term would be generated, edited
in accordance with the decision, and the previous version
would be flagged as obsolete.
_ Also info on domains in case of domain-specific terms?
The recent exchange of postings has raised to me some more
fundamental issues with how we handle status. I want to post
about this soon and hope we will have time to discuss in Bath.
_ We also need to be clear who are the end-users of the VMS. As I see it the
_ Usage Board is the user of the VMS, whereas other 'users' both human and
_ machine interact with the registry.
I agree.
_ Another issue is where does the scheme registration take place.... in the
_ Registry or the VMS.
In the VMS, I should think. There will be a need for internal
change tracking there as well -- might as well use the same model??
Improvements needed in Web documentation:
-- "accessibility" (Liddy), though I'm not sure what this means
specifically for these documents...?
-- layout: wider spacing on Decisions (Liddy), others...?
-- font: not courier - which ones are "normal"...?
-- URI identifiers for terms should, ideally, not be "clickable"
-- Stuart wants different "view"
Issues related to elements-qualifiers:
== Should all encoding schemes for Identifier hold also for
Relation and Source? Do we need to capture this in our
documentation?
== Encoding scheme "URI" for Description and Rights (Rebecca,
Oct 12 2001)
== Articulate guidelines on using URIs as values, for example:
In Identifier, Relation and Source, the use of 'URI' as an
encoding scheme means "here is the value and it is a URI".
In Rights and Description, the use of 'URI' as an encoding
scheme would mean "the value can be found at the following
URI". These two things are not the same and therefore
shouldn't be encoded using the same mechanism. (Andy, Oct
14 2001)
------------------------------------------------------
Tom proposes:
------------------------------------------------------
-- The chair maintains the Agenda, which cites links to
all supporting documentation, including JISCMAIL postings,
that are relevant to the Usage Board agenda points.
The shepherd or discussion leader for each agenda point
will choose the relevant materials.
-- Unless IP issues are involved, all of the materials pointed
to in the agenda should be archived at http://dublincore.org/
after the final pre-meeting version of the agenda has been
distributed. [Alternatively, proposals could be archived
before the public comment period?]
-- A meeting packet of these materials will be distributed as
a PDF file.
-- After the meeting, the archival version of the Agenda
should be edited to point to the archival copies of the
materials cited.
If we agree in Bath that this is a good method, we could use
them to flesh out Section 4.2 of Process.