I wondered too whether assignment of an ISBN (or similar UPC) would be considered a component of the ProviderEvent.  That would clearly individuate such events to particular publications.

Stephen

On Fri, Jun 12, 2015 at 2:34 PM, Karen Coyle <[log in to unmask]> wrote:
Re-using the event makes sense to me for an issue of a journal, when you are cataloging individual articles. In that case, though, I assume that the publication event would be linked to the issue information. (Hmmm. Serials are always so much more complex than monographs.) I would always consider the publication of each individual book as a unique event, regardless of the data that is used to describe it. The fact that we record only the year as the date of the event is an artifact of title pages, I believe. If you take your data from Amazon (or Books in Print) you may get a full date. I suppose that it could happen that a publisher puts out two different books on the same day, but I still can't turn those into a single event in my mind.

kc


On 6/12/15 11:30 AM, Fallgren, Nancy (NIH/NLM) [E] wrote:

Hi Stephen,

 

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?

 

-Nancy

 

From: Stephen Hearn [mailto:[log in to unmask]]
Sent: Friday, June 12, 2015 1:54 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] NLM BIBFRAME update

 

Would all 2009 publications from U Mass Press reference the same ProviderEvent, or is each publication considered to have a ProviderEvent of its own? 

 

Stephen

 

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/PE2a bf:ProviderEvent  ;

rdam:publicationStatement ‘Amherst : University of Massachusetts Press, [2009]’  ;

bf:providerPlace  ‘http://NLMCAMMS/GeogAuth/P101 ;

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

kc

 

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 Fallgren

Nancy J. Fallgren

Metadata Specialist Librarian

Cataloging and Metadata Management Section

Technical Services Division

National Library of Medicine

 

Links

BIBFRAME-NLM GitHub repository

 

BF Lite core spreadsheet

 

Mockup: The contributions of Rudolph Virchow

 

Mockup: The myth of the addicted army

 

BF Lite

Library of Congress BIBFRAME Implementation Register

 

 

 

 

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: 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

ORCID:  0000-0002-3590-1242


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: 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
Ph: 612-625-2328
Fx: 612-625-3428
ORCID:  0000-0002-3590-1242