Hello Rob! > > CERN may use a subset of Marc21 where most of the indicators are > > __. Ok, that's CERNs library decission.
I'm not sure that the /LIBRARY/ was asked as much as it should be. ;) But this is another issue. > > But if the Invenio > > developers claim that Invenio supports Marc21, you *must* allow > > other indicators there, and consider it valid. > > Then don't say it supports MARC21. Simple solution. Frankly, using Marc21 as internal format is /THE/ selling point for Invenio. Doesn't sound sensible to drop it. But nobody whats to anyway, I think. > The primary goal of invenio should be to meet the needs of its > original institution(s). Then you get a solution for a small island only. Something like this has no future. One should have leared that from all those large IT projects of the past, especially all those large ambitious projects that just failed. The second selling point of invenio is that it doesn't try to be a solution for an island. > If marc indicators are not necessary in the database functions of > the originating institution, then feel free to ignore them. Avoid > getting dragged back 40 years to the days of library catalogs by any > mandates to follow every rule to the letter. Those rules may have > made sense in 1970 but they don't always now. Still, you'll have the largest set of data available in those formats. You will agree, that it can't be the goal to recatalogue all libraries in the world. And even if, I would strongly resist to recatalogue it to "the currently favoured standard from IT point of view" cause usually those standards change every other month. ;) So, what I want to say is that with the usuage of Marc you have access to a host of data and a huge amount of work accomplished over decades by probably millions of dilligent people. And you'll agree that data exchange is one of the strong points in current IT. One wouldn't like to drop that just to do everything again and again at every other place. This is even worse than reusing typwriters to produce paper cards. I'm sure you don't want to propose that. > And MARC development has been under the control of library > association committees, made up of librarians, who make decisions > based on cataloging rules for description of items Yepp. This is exactly what we do: describe real world items. Unfortunatly, it is not enough to describe something that would be nice if it would be standardized. We have to describe what we get and have. Unfortunately, real life is not always simple and rarely ideal. > (as typed on paper cards) Well, only the smalest libaries still use paper cards today. Still, it could be more efficient to use them than to introduce a computer. (Really... OSI-layer 8 might interfere destructivley. Often, layer 8 is /not/ the librarian, but this strange guy called "user".) > and not contemporary technology. If we would build a library on "contemporary technlogy" at point t we would have to rebuild all libraries every other month or so. Note, that you're talking about 10^6 entries for every average sized university library. Please note also, though we librarians might be simple minded people, that quite a bunch of those rules we invented result from the simple fact, that literature is not that much unified as you might wish for. Just two very common examples: * We print books for some 500 years. Till now, not even the page formats are unified. Even though it sounds much more efficent to produce paper of only say 5 differen sizes, right? BTW: this also causes quite practical problems if you have to shelf those items... BTW/2: this unification happend for the paper of your office printer. So it is possible in principle. Right? * There're still people how believe an ISBN to be unique. This is far from true. Almost every librarian knows that, still I know a bunch of funny IT solutions that take the ISBN as primary key. Oh, it works till you open up a real library. For the first 10.000 entires it might be "good enough". > It is important to remember that marc, was originally a U.S. Library of > Congress file format designed for large main-frame machines in a day of > top down programming, and magnetic tape reel storage. So the point is, that it was efficent on a machine with the computing power of my pocket calculator. Surely this should be able to work on a current workstation ;) No, I do not want to emulate a main frame and a tape storage. > Access was entirely sequential which explains some of the record > architecture. the format was intended to be used to generate paper > file cards. Agree. I also agree on it's limitations. I also agree that you might have more efficient means of storage and data handling nowadays. Still it should be possible to handle ingestion and dissemitation of "what we have", seemlessly. Especially with such an advanced a technology. Come on, if my pocket calculator could handle it... ;) > Modern computing should have freedom to use marc in any way that > makes it as suitable as possible for the job and not be hindered by > any marc or cataloging rules that are no longer really applicable. You miss some very crucial points here. Just two examples. - We have billions of records in this format. - We have thousands of people /extremely/ skilled in this format, some trained for years. I have collegues who don't even think in terms like "title" or "author" but in 2450<have to look at> and 1001_. I do this myself if I want to refer to something unambigiously. We reintroduced this in our project as "words where not good enough". So even non-libarians learnd marc so we were able to talk about the same entities efficiently. Especially the latter point gets slightly underestimated if you take the pure IT point of view. Anyway, just consider that if I can do something in Marc I can easily find say 20 people in my (small) library (~50% of it's staff!) who could handle it. Take /any/ other format and I have probably 2 or 3 left with some IT background. And I will need to invest huge ammounts of time for training to get something similar. But, I'll never get the same quality I get from people trained and used to something they do for a decade or so. You might call this "unfortunate", but it is just a fact. Thus, it could even be an economic argument. Sad to say, but cataloguers, even skilled cataloguers, are just cheaper than IT professionals. And they are fast at a very low error rate with the stuff they are used to. Though I'm no cataloguer, I am myself much faster in text marc than in MarcXML, cause it's not that chatty. Also my error rate is lower. I'm much faster to even jot down the record in text marc from scratch than with any fancy form-based interface. Depending on what you have to do this is a curcial factor. If I need to correct an error in say 1000 records it is usually more cost effective to just give them to our cataloguers than to write a program that finds all exceptions and handles them well. (For 1000 records usually I don't consider programming, if it is a one time issue.) This however requires that Marc is Marc as it should be and not only some subset of it. In sum: libraries are built for a slightly longer time frame than "current technology". Thus we change slower, but we also work for a much longer time. Most likely, even IT development will get much slower, in, say 450 years from now, when it reaches the age of our institutions. Probably, we could then use "contemporary technology" ;) -- Kind regards, Alexander Wagner Subject Specialist Central Library 52425 Juelich mail : a.wag...@fz-juelich.de phone: +49 2461 61-1586 Fax : +49 2461 61-6103 www.fz-juelich.de/zb/DE/zb-fi ________________________________________ From: Rob Atkinson [atkin...@fnal.gov] Sent: Friday, March 28, 2014 17:08 To: Ferran Jorba; Esteban Gabancho Cc: Wagner, Alexander; project-invenio-devel (Invenio developers mailing-list) Subject: Re: Please allow any indicator in any field On 03/28/2014 04:39 AM, Ferran Jorba wrote: > the problem is more general in Invenio. You can take Marc21 and use a > subset of it. Or just use a subset of the tags. Or interpret more > strictly, more loosely, use more local tags or subfields. Marc21 is > like a legal code (or a programming language, if you feel more > confortable with), where there is flexibility. > > CERN may use a subset of Marc21 where most of the indicators are __. > Ok, that's CERNs library decission. But if the Invenio developers claim > that Invenio supports Marc21, you *must* allow other indicators there, > and consider it valid. Then don't say it supports MARC21. Simple solution. The primary goal of invenio should be to meet the needs of its original institution(s). If marc indicators are not necessary in the database functions of the originating institution, then feel free to ignore them. Avoid getting dragged back 40 years to the days of library catalogs by any mandates to follow every rule to the letter. Those rules may have made sense in 1970 but they don't always now. And MARC development has been under the control of library association committees, made up of librarians, who make decisions based on cataloging rules for description of items (as typed on paper cards) and not contemporary technology. It is important to remember that marc, was originally a U.S. Library of Congress file format designed for large main-frame machines in a day of top down programming, and magnetic tape reel storage. Access was entirely sequential which explains some of the record architecture. the format was intended to be used to generate paper file cards. Modern computing should have freedom to use marc in any way that makes it as suitable as possible for the job and not be hindered by any marc or cataloging rules that are no longer really applicable. Rob ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
