Print

Print


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] <[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/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]
>
>
>
> *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] 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
>
>
> --
> Karen [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