On 14/05/2013 15:03, Mitchell, Michael wrote:
The difference I see is that to my mind “record” implies a database entry with fields and subfields. BibFrame will not entail database records, fields, or subfields. It will be much closer to an XML file which is quite different structurally and semantically from a database record although I realize crosswalks are common. You can call it Frank but it still is a different animal with a different structure and some content rules will fit it better than others.
My apologies if I took us off topic on this tangent. I don’t mean to belabor the point but I do think the more we can understand where, and where we are not, headed with RDA and BibFrame, the better we can understand what is important to address now (punctuation, capitalization?). I also think the more of us catalogers involved in BibFrame development the better the fit will be in the end. There seem to be precious few practicing catalogers in the mix now. I don’t know much about the info sci end of the development but I do know cataloging and can cry foul when I recognize a problem.
What I am trying to point out is that the future situation will not be all that much different fundamentally from the way it is now. Our current records in our databases are not now sitting there as database records, comprised of fields and subfields. (Except for CDS-ISIS databases, at least) What we perceive as single records are actually cut-up and scattered hither and yon among all kinds of different tables, sometimes even duplicating the information for internal purposes. If you are able to examine the tables themselves, everything seems to be complete chaos.
But when you view information for a specific resource however, the system uses specific internal numbers to bring everything together to provide coherence, so that you can get an OPAC display of a single resource, or another display for a cataloger. In both cases, people perceive these as single bibliographic or authority records but within the system they are not. The new format will be similar, I am sure. This is why I say that it is proper to speak of “records” since that’s the way we speak of them now and essentially the same situation will apply.
Stlll, BIBFRAME will be quite different from MARC21, but MARC21 is a communications format. True MARC21 records are used only for the split-second when records from one library catalog (stored in relational database format) are transferred into another using Z39.50. Once the record is brought into the second catalog, it is then sliced and diced according to the second relational database, probably in quite different ways than it was in the first catalog. The new type of format should allow other programs to use BIBFRAME records (that is, to “communicate” with them) much more easily in all kinds of ways. But those other programs will do much the same thing: they will slice and dice the BIBFRAME records in ways they prefer, probably in ways that we would consider to be very strange.
It doesn’t seem as if the work of the cataloger will change much (except new words for the same things) and catalogs themselves will probably not change all that much either from what they can do now. Lucene-type indexing can improve immensely. Our catalogs already can ingest all kinds of records and they could do a lot more if we wanted, and our catalogs could include many more mashups. Libraries will be able to build APIs much more easily. The biggest difference people will see will be that other sites will be able to use our records (that’s the idea of linked data after all) and, if we are lucky and webmasters actually decide to use our records, we will see them in all kinds of places outside of library catalogs. This will be very strange but at least that would show that they are being used.
Although I agree with the BIBFRAME project and it should have been done long before RDA was ever begun, to be honest, it is still not completely clear to me who BIBFRAME is aimed at.