I wanted to chime in here since Authority Control is near and dear to
my heart.
What Larry is suggesting makes perfect sense to the end users like
metadata librarians
and catalog librarians. The authority record provides several things
to the users:
1. Authorized form of the heading.
2. Search Under references (un-authorized forms)
3. Search ALSO Under references
4. Bibliographical data for the referencing of the authorized form of
the heading
5. Epitome notes
6. Tracing practices (for series)
7. Scope notes for explaining how a heading works to the public
(especially with
LCSH, MeSH, and ATT headings).
The issues with Controlled Vocabulary as used now in DSpace is that
it is not
dynamically updatable. The metadata specialist or librarian is not
able to
add terms to the Controlled Vocabulary. That poses real problems when
working with
Library of Congress Subject Headings. While LCSH represents about
300,000 controlled
terms, it allows for the flexibility to create pre-coordinated
search strings.
For example, United States is an LCSH term. Metadata specialists may
wish to
add History and further 1961-1969, so you end up with the following
controlled heading on the fly:
United States--History--1961-1969.
DCMI does not really address these issues. After reading the
documentation, not even
OCLC has implemented this. The closest they have come is the Authority
Name Service which, by the way, uses the OCLC Authority Files as a
basis for its
creation.
Now we see the crux of the problem with different metadata standards
of DC, MARC21, EAD
MODs, VRA, etc. The newest standards have not dealt well with
authority control, or dealt with
it at all.
For those who work with Library's ILSes, (Integrated Library Systems),
you will find the
the authority record is able to control the headings in the
bibliographic records (or the
item metadata as we say in DSpace) automatically by correcting the
headings during
after hour processing, or in real update time.
While staffing is lean across the board, I think what Larry s
proposing is one I would jump on
in a flash with no hesitation. Using DCMI as it is, may in the long
run, could prose larger
problems since it is, as they say, projection-ware .
My $.03 worth. My apologies if I have offended anyone.
Jeffrey Trimble
System LIbrarian
William F. Maag Library
Youngstown State University
330.941.2483 (Office)
jtrim...@cc.ysu.edu
http://www.maag.ysu.edu
http://digital.maag.ysu.edu
On May 14, 2009, at 12:54 AM, Mark Diggory wrote:
Larry,
I think this would be an interesting project. But I will propose
three points of concern.
1.) Authority Control aligns with Vocabulary Encoding Constraints
found in the the DCMI DescriptionSetProfile
(http://dublincore.org/architecturewiki/DescriptionSetProfile). More
specifically, DCMI Vocabulary constraints allow for a Vocabulary
Encoding to be defined and asserted on metadata values. We are
working to express and utilize this for the DSpace 2.0 Metadata
Management and it would assist us highly if the implementation of
Authority Control took this model and its domain into consideration
when being implemented. This is an example of our trying to assure
that changes made to 1.6 align with 2.0 and provide a stepping stone
for 1.5 users to 2.0. See:
https://scm.dspace.org/svn/repo/dspace2/trunk/api/src/main/java/org/dspace/services/model/metadata/NonLiteralConstraint.java
and consider that Vocabulary Encoding Constraints have their own set
of attributes it might be valuable to consider.
2.) Resources are spread pretty thin in the DSpace community and
catching, evaluating and committing in-house projects thrown over the
wall is quickly becoming a thing of the past. I would recommend that
if this is something you want to see gotten into the codebase,
seriously consider getting the permissions necessary to do it yourself
(or perhaps permissions to do your proof of concept in an svn branch
at scm.dspace.org/svn/repo/dspace/branches first) and then merging it
in shortly afterward before it significantly deviates. With the new
granular svn access controls this is indeed a tractable. My concern
is that the 1.6 projects are piling up and assuring work is gotten in
requires time and effort on the part of the stakeholder.
3.) Confidence is an interesting idea, but certainly not part of the
DCMI DescriptionSetProfile. We do need to consider how we will encode
assertions about metadata fields assigned to a resource, not only
something like confidence, but also, for instance who asserted it and
policies on its management. This reminds me of your
BitstreamFormatRenovation work, something I still consider important
to get into DSpace. Considering not using the Data Model to directly
encode this, but instead looking to the same Service Architecture
strategy employed in 2.0 where alterations are encapsulated in a
separate model, service and persistence
