Print

Print


Charley, I asked my LTI contact about preparing for the non-MARC future, and she expects that it will take a long time for all the clients (many of them smaller libraries) to get off MARC, and in the meantime there will be crosswalks and LTI will continue to use the routines that they have built around MARC.  It is hard to imagine how else to prepare, given so many open questions about where we are going!  Once the general direction becomes more certain, I expect that flexible vendors will find a niche.  If our databases become less local and more linked back to LC, etc., there are services that could be sold to those big players.

Thinking a little bit more about my basic idea of programs and catalogers working together, maybe what we need is a system that is programmed to recognize standard use of A, an, the, la, le, etc. (which people often miss), while exceptions are somehow coded.   Especially if we are linking back to a master record at LC, etc., even if exceptional cases are not recognized at first, they would eventually be caught.   All this assuming that searching protocols of the future don't make the whole issue just seem "SO 20th century."

Amy



-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Charles Pennell
Sent: Monday, February 11, 2013 10:18 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Filing indicators

I've imagined that non-filing indicators would be handled using mark-up that isolates the skip characters in much the same way we do at present for other XML mark-up schemas.  Of course, as with MARC, that assumes that the coder notices (or perhaps recognizes, in the case of non-native languages) the words to be skipped!  We've all encountered MARC records, either locally or from our utilities, that have non-filing indicators that are zeroed out or off-count.  We usually find these through a browse of the indexes or through random encounter.

Which brings up another interesting question, namely how are the LTIs and Marcives of the world prepping themselves for a non-MARC future, since we are talking about revenue streams here.  At the root of this question is the question of how they are prepping themselves for a world of linked data in which libraries link back to LC, NLM, NAL, Getty, OCLC, BL, or LAC rather than to the vendors?

   Charley

On Mon, Feb 11, 2013 at 9:38 AM, Amy Turner <[log in to unmask]> wrote:
> The language code in the record as a whole is used for the 245; since 740s can be in different languages, different protocols are used.
>
> Good point about language recognition on short strings.   My main point was that we should be thinking "outside the box" re non-filing indicators.   Reinhold Heuvelmann's post alludes to several possibilities.  He writes " While it may be true that there are technical provisions to try and figure out, I'd still prefer to rely on the people cataloging, and their experiences."   Our experience with the LTI fix indicates that while catalogers as a group have a lot of knowledge about the ins and outs of non-filing indicators, there is a high error rate even at an institution that has traditionally prided itself on examining copy carefully.   The ideal system should use programming based on human experiences to  identify human error, with fine tuning for odd cases that look like error.
>
> Amy
>
> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] On Behalf Of Tom Emerson
> Sent: Monday, February 11, 2013 9:22 AM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Filing indicators
>
> Amy Turner writes:
> [...]
>> They work from the language code, lists of articles by language, 
>> lists of exceptional phrases "A is for ...", and specific cases of 
>> titles that are not in the language of the text.
>
> Do you find that records have valid language codes for specific fields like titles? In my experience the language codes, if they exist, can be inconsistent.
>
>> Language recognition software, rather than the language code, could 
>> be used (Following LTI processing, we corrected hundreds of language 
>> codes that erroneous non-filing fix had revealed).
>
> On short strings language recognition is very difficult: I haven't had much luck with it on strings under 250 characters or so.
>
>     -tree



--
Charley Pennell
Principal Cataloger
NCSU Libraries
North Carolina State University