The "extended addressing" problem--or in this case the generic
extended field length problem--was solved a long time ago in data
communications. In X.25, for example, the address field is 8-bits wide
except where, by mutual agreement, extended addressing is used. If the
first bit is set (1) then the next byte is also part of the address.
This can go on for multiple bytes, until finally the last byte of the
address has a 0 in the first bit. No reason this couldn't be adopted
in the NGC world, too.
So, I think what I'm getting out of this discussion is that I haven't
ever read about any explicit requirements for an internal data
representation because the requirement is that the record is basically
the entire work, with appropriate field delimiters of course, plus
subject headings and other librarian-added value. Am I on the right
track?
On 8/25/07, Karen Coyle <kcoyle_at_kcoyle.net> wrote:
> Once again, from the "reality check" files.... ;-)
>
> KREYCHE, MICHAEL wrote:
>
> >
> > The 99999 limit is maybe the most burning problem with the current
> > MARC21 implementation. Other possible changes--length of tags, fields,
> > indicators, etc. just aren't going to happen because there is no
> > immediate practical need for them.
>
> There is a great need to expand the subfields. There are a number of
> fields where all or nearly all of the subfields have been assigned, but
> there are desired additions to the field. I ran into this in the 773
> field when I was asked to modify it to be more in line with the data
> coming from A&I databases. (773 is where you would put a journal
> citation in MARC). There were not enough subfields remaining to create
> separate data elements for volume, number, part, and pagination.
>
> There's another problem, which is that the subfields have sometimes been
> treated as mnemonic -- $u for the URL -- and people don't want to have
> to work with a different subfield for the same data element in different
> fields. What this tells me is that there are certain "universals" that
> need to be included in the field definition (we already have that in
> some of the numeric fields), and that it's easier for those doing input
> if those common elements always appear the same. This is one of the
> things that MODS is able to do -- by using terms rather than subfields
> -- although I can think of other ways to do it, by defining the field as
> having certain characteristics (linking, URLs, identifiers, etc.) rather
> than treating those as subfields.
>
> MARCXML, although it solves the length problems, carries with it all of
> the limitations in the current subfielding. What intrigues me about the
> ISO marcXchange format is that it is a step toward solving the
> subfielding problem.
>
> However, once I get my mind around marcXchange, I start wondering about
> the field/subfield/indicator pattern altogether. This is what leads me
> to want to try the "RDA in RDF" approach, creating something much more
> atomistic and allowing systems to build data stores where rather than
> large, complex records you have interacting "entities." It's still a
> vague picture in my mind, and I don't know how it works for exchange.
> Then again, I'm beginning to think that we might want to think less
> about sending large amounts of data into many thousands of separate
> databases and more about sharing data that lives someplace we can all
> get to. Again, somewhat vague, but here are some examples: Do we want to
> import into our catalogs records for Google Books, or do we want a
> service that allows us to link to Google books from bibliographic
> records and from searches? Do we want to import tables of contents for
> all of our books, or have a service that allows us to access them from
> bibliographic records and from searches? Does saving all of this data
> redundantly in thousands of catalogs make sense today? That's what I'm
> thinking about.
>
> kc
>
> --
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> kcoyle@kcoyle.net http://www.kcoyle.net
> ph.: 510-540-7596 skype: kcoylenet
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
>
--
Sharon M. Foster, B.S., J.D., 0.58 * (MLS)
F/OSS Evangelist
Cheshire Public Library
104 Main Street
Cheshire, CT 06410
http://www.cheshirelibrary.org
My library school portfolio: http://home.southernct.edu/~fosters4/
My final project for ILS655, Digital Libraries:
http://www.vsa-software.com/ils655
Any opinions expressed here are entirely my own.
Received on Fri Aug 31 2007 - 09:23:02 EDT