While we're brainstorming....
We've been talking about an authority file, but not how we'd use it. It
could be like LC authorities, that we use for "copy" -- that is, when we
need to add a new entry to our own catalogs, we ingest that entry from
the community file. This is a use that would require minimum support in
that the file is used once by a library for new entries. The library
system would then do the indexing an display that interacts with the
user view of the bibliographic data.
The other use would be if we actually pointed our catalogs at this file
and somehow used the data dynamically in the user view. This would be a
much heavier use of the system, and would require a great deal more
cycles and bandwidth.
I presume we are talking about the first use, a large database of
authority "copy" that can be updated by librarians but that is mainly
used to download data into library catalogs. This is basically the NACO
model, although in that one a small set of elite libraries is authorized
to add and change records. And there's no reason why this "wiki" model
couldn't limit input to a trusted set of experts. Or at least limit the
"record" portion to experts, and allow other users to have a sandbox for
whatever information they wish to add.
I still don't see it requiring a whole OCLC-like structure for hardware
and staffing. It'll be a reasonably big database, but the hits against
it will be somewhat low... unless it ends up appearing on the first
pages in Google searches.
kc
Stephens Owen wrote:
> 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
>
> **************************************************************
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Fri May 25 2007 - 09:05:57 EDT