[log in to unmask]" type="cite">
Interesting question. Our mockups represent 2 options for modeling bibliographic data, but certainly not all possibilities. Our approach to Provider Events in the mockups is that they are each unique to an Instance, i.e., not re-used. However, there’s nothing to keep someone from experimenting with re-using Provider Event ids and thinking that option through more thoroughly. Some questions to consider:
· What would you hope to achieve by re-using Provider Events?
· What would re-using Provider Events buy you v. having them unique to each Instance?
· Is it viable to locally store an ‘authority file’ of Provider Events for re-use? Do identical Provider Events recur often enough to make that worthwhile or will you mostly have one-offs?
Would all 2009 publications from U Mass Press reference the same ProviderEvent, or is each publication considered to have a ProviderEvent of its own?
On Fri, Jun 12, 2015 at 11:46 AM, Karen Coyle <[log in to unmask]> wrote:
Thanks, Nancy. The examples are very interesting.
I want to point out, since it comes up here and elsewhere, that bibfra.me is handling the publication statement problem (e.g. how to keep the publication information together as a unit) by treating publication as an event with its own graph:
‘http://NLMCAMMS/Event/PE2’ a bf:ProviderEvent ;
rdam:publicationStatement ‘Amherst : University of Massachusetts Press, ’ ;
bf:providerPlace ‘http://NLMCAMMS/Countries/C002’ ;
bf:provider ‘http://NLMCAMMS/NameAuth/A200’ ;
bf:providerDate ‘2009’ .
FRBRoo also defines publication/production as an event, and that allows you to say specific things about that event. I think this is a good way to view this data. I'd also be interested to hear how/if this works for non-book materials whose production processes may be different from those of print materials (e.g. films, performances).
On 6/11/15 4:21 PM, Fallgren, Nancy (NIH/NLM) [E] wrote:
In November 2014, the National Library of Medicine (NLM) announced that it was taking a different approach to BIBFRAME (BF) experimentation (see NLM’s Early Implementers registration). This new approach involved development of a core, widely shareable BF vocabulary that could be extended for greater granularity with existing descriptive schema. In pursuit of this goal, NLM has been collaborating with Zepheira, George Washington University (GWU), and University of California, Davis (UCD) in development of the BF Lite vocabulary, as hosted by Zepheira. Part of the perspective NLM brings to this collaboration is a focus on creating new cataloging data directly in BF rather than converting legacy bibliographic data.
The scope of NLM’s work on BF development to date has been deliberately narrow in order to keep short term goals modest and achievable. NLM and GWU produced a spreadsheet that correlated BF Lite with PCC RDA BIBCO Standard Record (BSR) elements and RDA RDF properties. The broader group of collaborators used that spreadsheet as a starting point for discussion, evolving it to a static snapshot (as of 6/8/2015) of a portion of the BF Lite core vocabulary. The resulting spreadsheet includes BF Lite properties and classes that expand beyond the BSR elements, but that NLM and GWU believe are appropriate for cataloging print monographs. In contrast, the BF Lite vocabulary on http://bibfra.me continues to evolve and includes properties and classes that are applicable more broadly than print monographs.
To demonstrate how the BF Lite core vocabulary in the spreadsheet can be applied, NLM and GWU manually produced two mockups of original BF cataloging using that vocabulary with extensions from other schema. Each mockup provides two examples of cataloging a print monograph using BF Lite with a modular approach: one extends BF Lite mainly with Zepheira’s BF extended vocabularies and the other extends BF Lite mainly with RDA RDF properties. These mockups are publicly available on Google Drive: The myth of the addicted army and The contributions of Rudolph Virchow.
The experimental BF vocabulary and mappings released with this announcement are not complete or final, but rather a starting point. We believe our efforts have produced a vocabulary sufficient to test the theory that a BF vocabulary built from a core of widely shareable properties provides flexibility and extensibility for describing diverse resources. It is our hope and expectation that both the spreadsheet and the BF Lite core vocabulary will be used by the community for experimentation, so that BF can evolve and develop in a tested, community driven manner. NLM believes that BF development is still fluid and should evolve through thoughtful vetting and testing, with emphasis on creating new data rather than converting legacy data.
NLM welcomes community feedback about our experimentation. We have set up a public GitHub repository named BIBFRAME-NLM, where we request that you post all comments, issues and questions. An expanded version of this announcement and links to related documents above can be found in the ‘read me’ section of the BIBFRAME-NLM repository. There is no login required to view the documents or to view comments and issues in the BIBFRAME-NLM repository; however, you will need to create a GitHub username and password to contribute comments, issues, or questions. When contributing comments, issues, or questions, please apply the prepopulated labels indicating what you are commenting on, e.g., the spreadsheet, the mockups, etc.
On behalf of the NLM BIBFRAME Team,
Nancy J. Fallgren
Metadata Specialist Librarian
Cataloging and Metadata Management Section
Technical Services Division
National Library of Medicine
BIBFRAME-NLM GitHub repository
BF Lite core spreadsheet
Mockup: The contributions of Rudolph Virchow
Mockup: The myth of the addicted army
Library of Congress BIBFRAME Implementation Register
--Karen Coyleskype: kcoylenet/+1-510-984-3600
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
-- Karen Coyle [log in to unmask] http://kcoyle.net m: +1-510-435-8234 skype: kcoylenet/+1-510-984-3600