Le 22 janv. 08 à 17:39, Galen Charlton a écrit :

As far as I can tell, only the third approach currently links bib headings to authority records.

In unimarc, another approach is to generate marc records with appropriate $9 fields and bulkmarcimport them, but you also have to take care to fill in the $a $b (7XX) and $a $x (6XX).

I think at one time (and maybe even now?) there was a batch job that would go through existing bibs and existing authorities and link bib headings to authority records, but I don't think it still exists or works.

I guess you refer to migration_tools/build6XX.pl, it still exists but I couldn't make it work (and was only for 6XX fields).

kohaenv ./build6xx.pl Unrecognized character \xEF at ./build6xx.pl line 99.

I'm currently playing around with improving authority support,

I'm part of a project to migrate a catalogue from a proprietary ILS to a libre one. We are currently evaluating different systems and for us, one of the biggest drawback of koha is the way it manages authorities. You'll find below some of the criticisms. Bear in mind that some of them may be due to our misunderstanding on how to use the system, in that case do not hesitate to point it out. We are using koha 3 alpha with nozebra and unimarc. For now we are only using authorities for authors and subjects. Both were imported via the unimarc A standard and linked to records on import as suggested above. Our thesaurus for subjects is hierarchical, it was imported by putting subjects and their subdivisions in 250 $a $x $x ... we also have rejected forms (See) and associated forms (See also), which were respectively put in 450 $a $x $x ... and 550 $a $x $x... 1) Cataloguing We found it awkard to have a direct mention of the koha authority number in the interface. Moreover it is perfectly possible to use a koha authority number and fill in an author name (or subject) that is different from the autority. This will lead to strange search result since a search via authorities will not yield the same search as via the nozebra index. We would also like to be able to force the use of the thesaurus in the cataloguing interface. Currently the fields are too open, which is prone to data noise. In some sense you should be able to select an authority (or create if it fist if doesn't exist yet) but then the fields it fills in the record should not be editable -- even better this information should not be replicated in the record, only the authority number should be written, the rest is presentation by fetching from authorities. 2) Rejected and associated forms. Since rejected and associated forms are listed in authorities themselves, they won't show up if you do a search via the nozebra index. Moreover if you search by authorities rejected forms will only appear if you search "anywhere" in the authority (we don't really expect our users to be able to understand the subtelties between the various choices provided for authorities search, something like $a must be pretty cryptic to them). It would be nice if rejected forms could appear in the result list per se linked to their accepted form. Associated forms are only available in the austere marc view of authorities and they are not linked to they authority number. Besides when you search the catalogue for authorities (an: queries) it would be nice for the associated forms to be linked at the top of the page. Otherwise when you browse authorities through records you'll never get the information about the associated forms, for that you need to go the authority marc view. 3) Hierarchical thesaurus Subjects are not hierarchically browsable. All levels of the link of a hierarchical subject point to the same authority. Setting AuthDisplayHierarchy to 1 doesn't seem to change anything. I didn't really get anything about the support provided by koha for hierarchical thesauri. In some sense these remarks boil down the following two points : a) Authorities hierarchies, rejected and associated forms are poorely linked and hard to search/browse. b) Authorities don't really seem to be linked to records, each seems to live in its own search space (due to the indexing done on records only) Best, Daniel