Dear Sally,

Will tripping be possible also for MARC host / component part record combinations? They are used extensively over here for serial & music cataloguing.  See e.g.

Will the two-tiered record architecture (host - component part) be supported in the future format as well, either as interlinked records (the current model) or as a single record encompassing all the relevant metadata? And if the plan is to keep the current two tier structure, have you considered the need / possibility of introducing more tiers (as in e.g. serial / article / an image within the article)? 

For the documents digitized in house, we currently provide a lot of administrative metadata in MIX, PREMIS and other formats. Some, but not all, of the data elements supplied in the technical and preservation metadata are replicated in the MARC 21 record.

Will the future format be all-encompassing in the sense that all the bibliographic and administrative metadata we have currently have in MARC 21, MIX, PREMIS etc. could be migrated into the new format (and back again) if there is a valid business need to do that?  Given that in any well designed digitization pipeline most of the administrative metadata can be produced automatically replication of some data elements may not be too much of a problem at the production phase, but things do get a little bit complicated when information relevant to the end users is scattered and can not be easily harvested and passed on to other IR systems.  

Best regards,


On 4.12.2012 19:57, McCallum, Sally wrote:
[log in to unmask]" type="cite">

Owen,  If you remember we said last fall that that the aim was to provide for this kind of tripping and so the answer is yes to both questions.  Based on our experimentation thus far at LC, I would not expect the trips either way to be lossless, however, in some cases, a trip could actually add clarity to the source data. 


We are planning to make downloadable some transformation pipeline software (Python and XQuery versions) at the end of this week or early next that programmers can use to experiment as we have been doing.  They can tweak and change the code around and experiment with their ideas.  In January we also hope to have some transformation services open for experimentation.   I emphasize that these tools are to enable experimentation, not the final word on a or the transformation. 


The Early Experimenter team will be meeting here next week and we hope that some interesting data will come out of what they have done over the last 2 months that we and they will share with the community.


Your questions are  good ones  and good reminders that the past does exist.





Sally H. McCallum

Chief, Network Development and Standards Office

Library of Congress,  101 Independence Ave., SE

Washington, DC 20540  USA

[log in to unmask]

Tel. 1-202-707-5119 -- Fax 1-202-707-0115



From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Owen Stephens
Sent: Tuesday, December 04, 2012 10:08 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Le MARC 21 est mort, vive le MARC 21!


There are two questions in my mind around this, and if it is at all possible some explicit statements from LoC about these would be useful (to me at any rate):


1) Is the intention that it will be possible to automatically create Bibframe serialisations from existing MARC21 records

2) Is it the intention to be able to roundtrip records between Bibframe serialisation and a MARC21 record?


I have to admit that I've tacitly assumed (1) because I'm not sure how else it would be possible to transition from MARC21 in any forseeable timescale. (2) I suspect will be difficult to achieve, if indeed it is seen as desirable at all.




Owen Stephens

Owen Stephens Consulting

Email: [log in to unmask]
Telephone: 0121 288 6936



 Juha Hakala
 Senior advisor

 The National Library of Finland 
 P.O.Box 15 (Unioninkatu 36, room 503)
 FIN-00014 Helsinki University
 tel +358 9 191 44293