Print

Print


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] 
> <mailto:[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 <http://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 <http://nlmcamms/Event/PE2>’ *a 
> bf:ProviderEvent*  ;
>
> rdam:publicationStatement ‘Amherst : University of Massachusetts 
> Press, [2009]’  ;
>
> bf:providerPlace  ‘http://NLMCAMMS/GeogAuth/P101 
> <http://nlmcamms/GeogAuth/P101>’ <http://localauthority/NLMP101%27%20> ;
>
> bf:providerPlace ‘http://NLMCAMMS/Countries/C002 
> <http://nlmcamms/Countries/C002>’ ;
>
> bf:provider  ‘http://NLMCAMMS/NameAuth/A200 
> <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
>     <http://www.loc.gov/bibframe/implementation/register.html>). 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 <http://bibfra.me/>, 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
>     <https://docs.google.com/spreadsheets/d/1QM8X4qHd-D6ogftRHywBwIvKGyMa_5Kp3YgNEsv7KpU/edit?usp=sharing>
>     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
>     <https://docs.google.com/document/d/10jhz0P2bN_d_WZPmKDwhvQSDKrVvU99RWGiinKP6NUc/edit?usp=sharing>
>     and The contributions of Rudolph Virchow
>     <https://docs.google.com/document/d/1WNcOy56l6f1vswWCa4PTBvkjoSDo2T2U3cj69moYwX8/edit?usp=sharing>.
>
>     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
>     <https://github.com/fallgrennj/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
>
>     [log in to unmask] <mailto:[log in to unmask]>
>
>     *Links*
>
>     BIBFRAME-NLM GitHub repository
>
>     https://github.com/fallgrennj/BIBFRAME-NLM
>
>     BF Lite core spreadsheet
>
>     https://docs.google.com/spreadsheets/d/1QM8X4qHd-D6ogftRHywBwIvKGyMa_5Kp3YgNEsv7KpU/edit?usp=sharing
>
>     Mockup: The contributions of Rudolph Virchow
>
>     https://docs.google.com/document/d/1WNcOy56l6f1vswWCa4PTBvkjoSDo2T2U3cj69moYwX8/edit?usp=sharing
>
>     Mockup: The myth of the addicted army
>
>     https://docs.google.com/document/d/10jhz0P2bN_d_WZPmKDwhvQSDKrVvU99RWGiinKP6NUc/edit?usp=sharing
>
>     BF Lite
>
>     http://bibfra.me
>
>     Library of Congress BIBFRAME Implementation Register
>
>     http://www.loc.gov/bibframe/implementation/register.html
>
> -- 
> Karen Coyle
> [log in to unmask]  <mailto:[log in to unmask]>  http://kcoyle.net
> m:+1-510-435-8234  <tel:%2B1-510-435-8234>
> skype: kcoylenet/+1-510-984-3600  <tel:%2B1-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
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600