On 11 Oct 2007, at 8:51 PM, Adam M. Goldstein wrote: > 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. >
I know that. But what I mean is that sometimes in cases where they should be there they're missing, or not according to the specifications. >> 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'm just saying that specifications are one thing, but the practice is a whole other world, in my experience. I used to be more optimistic, before the many bug reports. >>>>> 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. We'd be happy to make use of your knowledge. Feel free to suggest new items to include or better mapping. Christiaan ------------------------------------------------------------------------- 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 Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
