Hello Rob,

> > 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.

Sorry, they do:

  Invenio complies with standards such as the ​Open Archives 
  metadata harvesting protocol (OAI-PMH) and uses ​MARC 21 as its
  underlying bibliographic format.
  <http://invenio-software.org/>

  Flexible metadata: Standard metadata format (MARC) 
  <http://invenio-software.org/wiki/General/Features>

  MARC format is the standard in the library world. It is well
  established and has been used since 1960s. [...]
  <http://invenio-demo.cern.ch/help/admin/howto-marc>

And those reasons were the ones we used to choose Invenio over the
other alternatives quite some years ago.

> The primary goal of invenio should be to meet the needs of its
> original institution(s).

«Primary goal» should not exclude others, specially when an easy
compatible solution exist: take any indicator as valid.  Not perfect,
but *much* better than now.

> 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.

That's why some institutions, like CERN or FNAL may take a subset of
Marc21.  But it turns out that there are millions, hundreds of millions
Marc21 records out there, outside those HEP institutions, where
those indicators exist.  And if the library community has decided that
indicators are useful, please respect their decissions.  That's not
what I'm discussing here.

What I'm proposing is that, just changing the developers mind and
taking into account that indicators may have different values that __,
and changing the code for %% or whatever wildcard character is
relevant, those existing records are going to be recognized by any
institution testing Invenio with default values, without having to
patch it as some of us have done.  I have discuraged Invenio to more
than one institution for those reasons.

> 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.

Yes.  For similar technological limitations Unix has those cryptic
abbreviations.  But both Marc an Unix, curiously both born at the
end of 1960s, have been proven much better than the alternatives, and
the reason that they still in use. And backwards compatibility with the
existing heritage has one of the reasons of its current value.
 
> 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.

Yes, of course.  But as compatibility is not so difficult, I argue that
it should be a goal for Invenio.  Even more as the current users have
records *with* indicators.  And let the librarians decide whether those
cataloging rules are applicable or not.  Most of the times they are
right.

Best regards,

Ferran

Reply via email to