Now can I be the one to name a technology and say OAI?
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 Jonathan Rochkind
Sent: 25 May 2007 16:19
To: NGC4LIB_at_listserv.nd.edu
Subject: Re: [NGC4LIB] Authority maintenance (was Subject costs)
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_at_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:21:25 EDT