Both 'wiki' and 'blog' are actually pretty vague terms in common usage,
and I think it would be more sensible to look at the functionality we
need to support, and then decide if a package is available that will
give us this functionality (or build it if necessary)
A wiki is simply a system "designed so that the content can be made
available in a quick and uncomplicated manner"
(http://en.wikipedia.org/wiki/Wiki) - in this sense 'wiki' describes the
function, not anything specific about the package or technology.
Although 'wiki' is now more commonly used to refer to applications that
allow the updating of web pages by a number of people, there is no
reason that a 'wiki' system shouldn't give access to structured data of
course.
A blog is essentially a website where entries are time/date-stamped.
There are a number of other technologies associated with 'blogs' and
there is a blogging api, but again, the idea is more important than the
technology.
So 'blog' software (like Wordpress) could be pressed into service here
(as it has in the examples given by Deirdre), but actually this is not
so much a 'blog' as leveraging Wordpress functionality (comments, RSS,
etc.) to display bibliographic data.
Lets start to map out the functionality that this community authority
file would need, then we can start to examine appropriate systems.
Starter for 10:
Support for user accounts
Ability to store structured authority records (in an xml format?)
Ability to edit data via a web interface
Ability to link edits to specific user accounts
Ability to store and display previous versions of structured authority
records
Ability to output authorities in MARC format
Ability to query authority data via a standard API
...
Not suggesting we need a full functional spec as such, but I think if we
break this down at least into some broad areas first, then we can see
the technology required.
Another useful approach would be for posts of narrative descriptions of
how it would work - this can also be really helpful in determining
functionality ('Bob sits down and points his browser at
http://non-authority.com, he is asked to register, and gets his new
password sent to his email address. He logs on, and immediately can
browse or search the authority file, etc.)
Owen
Owen Stephens
E-Strategy Co-ordinator
Royal Holloway, University of London
Egham
Surrey
UK
TW20 0EX
Email: owen.stephens_at_rhul.ac.uk
MSN: owen.stephens_at_rhul.ac.uk
Tel: 01784 443331
-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Routt, Deirdre (LIB)
Sent: 25 May 2007 14:30
To: NGC4LIB_at_listserv.nd.edu
Subject: Re: [NGC4LIB] Authority maintenance (was Subject costs)
Allen Mullen suggested using a wiki to set up an authority file for
series. I agree that we badly need some better form of authority control
for series. Yesterday (Thursday) I attended a class on using blogs. The
instructor (Michael Sauer, Technology Innovation Librarian at the
Nebraska Library Commission -- his blog is:
http://www.travelinlibrarian.info ) pointed out two very interesting
uses of blogs.
This first one is from Lamson Library, Plymouth State Library. It is a
library catalog that is somehow run through a blog:
http://lamson.wpopac.com/library/read/219038
This is from a historical society and local library. It has historic
pictures and some information. Again it uses blogging software (in a
much more obvious way):
http://westernspringshistory.org/
So, could we use a blog to do an authority file for series? It would
allow for controlled entries by registered authors (who would be
identified and signed) and more open comments by others. It just might
provide enough structure and control to do what we want. Is it
worthwhile setting up and seeing how it works? Of course, unlike data in
MARC format, exporting and importing to a system would be a total bear,
but at least it would be a place you could check on series authority
info and could still copy and paste.
Does this seem feasible? I'd be willing to help out in setting it up but
I would not have time to do maintenance or set up on my own.
Deirdre
Deirdre Routt
Technical Services Manager
Omaha Public Library
215 S 15 St
Omaha NE 68102
(402) 444-4997
droutt_at_omahapubliclibrary.org
-----Original Message-----
Date: Thu, 24 May 2007 08:01:39 -0700
From: MULLEN Allen <Allen.MULLEN_at_CI.EUGENE.OR.US>
Subject: Re: Authority maintenance (was Subject costs)
Ed Speer raises some very pertinent questions regarding maintenance of
authority data. In addition to discussing these, I'd suggest some
action on the part of the cataloging community.
There is an opportunity now to demonstrate that a collective social
network of librarians can develop and maintain an authority data set for
the series work that LC is no longer doing and that PCC libraries have
not addressed beyond series they encounter if and when these libraries
want to trace them (for those PCC libraries that choose to trace series
- some, like LC, have decided not to) or that libraries feed to them (if
the PCC library staff are open to it and have the resources to do this
work on behalf of other libraries). Clearly, there is a perceived need
among catalogers and, in public libraries at least, among reference
staff.
I'd like to suggest that a wiki might be constructed in such a way that
library staff (and others if they are interested) can enter and edit
data fields for series authority data. The idea is that anyone can
contribute a new heading but that the collective wisdom and knowledge of
those who know how to construct and document AACR2 series name headings
and tracings would maintain the integrity of the data. There is a need
- I construct new series headings several times a week when they are not
on an OCLC record at all or are in a 490 0 field.
This (or some variant that is technically possible) could be a model,
albeit with all of the attendant committees and task forces and policies
and papers that such weighty matters require in the cataloging world (as
well as an enhanced "control" factor that Ed Speer aptly points out is
necessary), for maintenance of LCSH if and when LC ever lessens or
relinquishes its commitment to maintenance of the vocabulary.
However, I'm ignorant enough that the technical question of whether said
data in a wiki setting could be constructed in such a way to allow
export of MARC in a format that can be readily imported into a library
ILS is possible. I'm guessing it is but those of you who are export.
Certainly, the control fields might be a challenge.
If it is possible, let's do it whether it is sanctioned by NACO, ALCTS,
OCLC or anyone else. If it is useful, it flies - if not, it crashes and
some other solution to the lack of reliable ongoing series authority
maintenance for collective use is developed (or, as the case is now, is
not). Is protestation and a return to individual library
decision-making all that catalogers are capable of when faced with
changes that lessen what gets handed to them on a tarnished silver
platter? I don't think so - don't mourn, organize to take
responsibility for what is deemed important.
Allen Mullen
who is willing to devote some time off-work to helping develop and
maintain such a system
**************************************************************
Received on Fri May 25 2007 - 08:35:52 EDT