On Oct 11, 2007, at 2:20 PM, Christiaan Hofman wrote: <snip>
> >>> That parser can in principle determine the indicators, but currently >>> they are ignored. They are not always included and are sometimes >>> inconsistent. I haven't found a real need for them for the fields we >>> parse. >>> >>>> I take it that is possible identify the contents of a subfield, >>>> e.g., >>>> B358 in this case being subfield a, indicated by $a. >>>> >> >> Well, in some cases, the indicator can tell if a name is in direct >> order or reverse order. It also is used to distinguish titles from >> subtitles in the 245 field, and this has standardly used punctuation, >> which I usually end up having to correct. >> > > Perhaps. But in the samples I have seen the indicators were used > often inconsistently or were missing. Some fields don't come with indicators and so their absence doesn't mean that they're missing. > Also in some formats they are not easy to get. This is a more serious worry. > Also this is subtle information, while often even > well documented standards not followed by some libraries, which may > break our importing mechanism for those libraries. So I don't really > trust all (or even most) libraries to do things right, therefore I > rather just ignore it if I'm not sure it's really worth it. > I am a good deal less pessmistic than you are about standards and how well they're followed; but in any case, regarding the indicators, it's not a big deal; but since we've had this discussion I have a better sense of what it might be possible to do with the parser. >>>> I am starting with subject terms, which I think should go into the >>>> keywords field. >>>> >>> >>> My problem is that there seem to be really a lot of fields that >>> could >>> be suitable for keywords. I think most users wouldn't want to >>> pollute >>> their keywords with too much trash. >>> >> >> There are some things that people probably do want, like library of >> congress subject headings; but maybe not. Generally the 600 fields >> are used for subjects of various kinds. I have been identifying those >> most likely to be useful with the hope that the parser can be >> tinkered with to put them in the keywords field. >> >> Currently subjects are imported from PubMed, so I am building up a >> subset of MeSH subject headings in my keywords field. A given record >> usually has lots and lots of those; a library catalog record will >> have at most three or four. I think it would be nice to do the same >> with the LoC keywords, or at least, not have to enter in the keywords >> myself from my own list at first, especially if I import a lot at >> once. >> >> If developers and other users really do think they don't want >> keywords brought in, let me know, and I won't keep up the effort. >> > > If there are fields that pretty consistently contain useful > information we could add them. But i know too little about the > general practice of MARC to know which fields are relevant, I don't > use it myself. > I know all too much about MARC and I am hoping that the information will be useful for BD users and not too hard to build in. -AMG ================================= Adam M. Goldstein PhD Assistant Professor of Philosophy Iona College -- email: [EMAIL PROTECTED] web: http://www.iona.edu/faculty/agoldstein/ tel: (914) 637-2717 post: Iona College Department of Philosophy 715 North Avenue New Rochelle, NY 10801 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
