Or you can blend your two approaches. You have your own local file, you
don't actually point at the community file for local uses (beyond
initial ingest)---BUT we have technical mechanisms in place to keep your
local file synchronized with the community file, automatically with very
little human intervention.
Jonathan
Karen Coyle wrote:
> 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
> ------------------------------------
>
--
Jonathan Rochkind
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Fri May 25 2007 - 09:09:37 EDT