[Koha-devel] Authority control - request for comments
Ian Walls
koha.sekjal at gmail.com
Mon Jun 11 15:16:30 CEST 2012
Jared,
All you plans are most excellent, and I've been thinking about (and to some
limited capacity, discussing) them for a while now. I'm glad to see them
on the road to reality.
A couple comments:
About point 13, adding a "Did you mean?" feature... this should be done in
a way that applies to Biblios, as well, as it has often been requested in
that context, and as we see with points 5 and 6, the mechanisms under
Authorities are very similar to those under Biblios.
I believe a 15th point is required: fixing Authority Types. Right now,
they are essentially hardcoded, looking at the presence of specific MARC
field numbers, and determining their Auth Type from that (during import, at
least). This means that newly created Authority Types wouldn't be
accessible unless:
1. They used a completely new Main Entry MARC field number
2. The code was edited to associate that field number with that Auth Type
One prime example: right now, LCSH and MeSH subject headings are both of
the Topical Term Auth Type. They have the same MARC structure, but belong
to different thesauri. As it stands, there is no easy way of
differentiating a heading from one thesaurus from that of another.
This may be out of scope for the work you're currently planning to do, but
I'd ask you to keep it in mind all the same, and do any development with an
eye towards making Authority Types more robustly supported.
All in all, very interesting and encouraging work, and I look forward to
testing it out!
Cheers,
-Ian
On Sat, Jun 9, 2012 at 7:51 AM, Jared Camins-Esakov <
jcamins at cpbibliography.com> wrote:
> Good time of day!
>
> I plan to do a great deal of work on the authority module, and I wanted to
> request that anyone with thoughts on the matter please share them with me.
> The RFC is on the wiki at
> http://wiki.koha-community.org/wiki/C_%26_P_Authority_Control_Improvements_RFCand I have copied the description below.
>
> Description
>
> The development is divided into 14 parts:
>
> 1. A dropdown box will be added to the authority browser in the OPAC
> allowing the user to choose which index to search in authorities: the
> keyword index, the match heading index (i.e. all heading fields), the
> preferred heading index, or the main entry only index. (bug 8206)
> 2. Because importing large authority files can result in unused
> authority records overwhelming used authority records in OPAC authority
> browse results, some libraries may want to disable the display of
> authorities which are not used in the bibliographic database. In order to
> make this possible (while still retaining the existing behavior of
> displaying all records in the authority file as a default), a system
> preference OPACShowUnusedAuthorities will be created, and a "Show all
> results" link added to search results when it is enabled. (bug 8205)
> 3. Because see also references in authority records are intended to
> refer to other authority records, they really ought to be turned into
> hyperlinks in the various authority displays. They will be made into
> hyperlinks (using the authid in $9 if available, or a search string
> otherwise) in both the OPAC and the staff client. (bug 3462)
> 4. At present, the only authority record view available in the OPAC is
> an "expanded MARC" view which is of no use to patrons, and limited use to
> librarians. We propose adding a user-friendly authority details view
> similar in design to the bib details view. (bug 8204)
> 5. Although the batch import functionality was originally designed
> with importing both bibliographic and authority records in mind, authority
> import was never actually implemented. This will be done quite simply, by
> adding an option to choose which type of record to import in the Stage MARC
> records tool. (bug 2060)
> 6. Match points will also be extended for use with authority records,
> again completing a feature for which stubs already existed. (bug 7475)
> 7. There is no way to export authority records other than via a direct
> SQL query, which makes it difficult for hosted libraries to get their data
> out of Koha without the help of their support vendors. We propose to change
> the "Export bibliographic/holdings" tool to the "Export data" tool, and add
> a tab to enable librarians with the proper permissions for the export tool
> to export their authority records directly from the staff client. (bug 8202)
> 8. Some librarians have requested the ability to save individual
> authority records, so a "Save authority" button will be added next to the
> "Edit" button when viewing authority records. (bug 8203)
> 9. One of the great promises of DOM indexing in Zebra (and the
> adoption of solr as an indexing technology) is the ability to incorporate
> alternate forms of headings into bib records when exporting bibs for
> indexing. We will add the plumbing for arbitrary record filters, and
> implement a filter that checks each heading in bib records for alternate
> forms, and includes them prior to exporting the record for indexing. (bug
> 7417)
> 10. Instead of using only textual strings for see also links, the
> ability to use $9 in see also fields in authority records (5xx in MARC21,
> NORMARC, and UNIMARC) will be added, to simplify heading disambiguation.
> This will enable us to create a value builder plugin using the existing
> thesaurus functionality that will automatically populate the see also
> heading control fields with metadata about the link (broader term, narrower
> term, etc.) (bug 8207)
> 11. Right now when cataloging, catalogers have only two options for
> adding a new authority: turn on AutoGenerateAuthorities, and later edit the
> authority record to justify its creation, or save the bib record they are
> working on, create a new authority record in the authority module, wait for
> the new record to be indexed, and open the bib record back up to use the
> authority finder plugin. We intend to add a "Create authority" button to
> the authority finder plugin which will allow the cataloger to create an
> authority in a new window and (similar to fast add in circ) automatically
> fill out the selected heading field in the bib record. (bug 8208)
> 12. At times, people may want to search for terms that are related to
> the one they search for. For example, someone interested in books about
> Feet may also be interested in all books about specific parts of feet,
> including books about Toes, Heels, etc. We will add three new special
> pseudo-CCL search prefixes which will first search the authority file for
> the specified heading, then search not just for that term but also for
> broader terms (pseudo-CCL prefix su-br:), narrower terms (pseudo-CCL prefix
> su-na:), or all related terms (pseudo-CCL prefix su-rl:). (bug 8211)
> 13. Because patrons may not always realize that they want to search
> for a related term instead of the term they entered, we will also add a
> "Did you mean?" feature to the OPAC, which suggests terms related to
> authorities that match the user's search. (bug 8209)
> 14. Although not all authority records contain useful information,
> many do, and depending on the type of collection, access to that
> information can be critical to both librarians and patrons. In order to
> simplify looking up authorities referred to in particular records, a link
> from subject headings to their related authorities will be added to the
> OPAC. A patch which adds this to the "normal" mode bib details display has
> already Passed QA (bug 5888), so unless an unsolvable problem is found with
> that patch, implementation will focus on the XSLT view. (bug 8210)
>
> Any questions or comments are welcome.
>
> Regards,
> Jared Camins-Esakov
>
> --
> Jared Camins-Esakov
> Bibliographer, C & P Bibliography Services, LLC
> (phone) +1 (917) 727-3445
> (e-mail) jcamins at cpbibliography.com
> (web) http://www.cpbibliography.com/
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120611/cf24c794/attachment.htm>
More information about the Koha-devel
mailing list