Print

Print


Kate, great examples! I can't imagine that any specialities that vary 
notably from general book cataloging will be served by a "one size fits 
all" cataloging code or data format. What seems to make sense to me 
would be to design extensions for these materials -- extensions that are 
under the purview of an organization that can represent that specialty. 
Music libraries - the Music Lib Assn. Rare books - maybe SLA? Serials - 
please someone take on serials so the rest of us don't have to think 
about them! Art - ARLIS. Just suggestions, but each community has a 
gathering place for experts, and should have control over its own data. 
Extensions would allow that.

I don't believe that any other way will satisfy the wide range of needs 
of everyone who describes cultural heritage objects.

kc

On 11/12/15 6:17 AM, Bowers, Kate A. wrote:
>
> Ah, hem. Special collections have a lot more they need to say about 
> "items" than are dreamt of in your philosophy. Currently most of those 
> things are kept in holdings records or in bib. records with $$3 or $$5 
> to specify the "institution" and/or "copy" to which it applies.
>
>
> Take, for example, this (author's own copy plus added material OCLC# 
> 864841712) Harvard University Archives catalog record: 
> http://id.lib.harvard.edu/aleph/013813873/catalog) 
> <http://id.lib.harvard.edu/aleph/013813873/catalog> and this (where 
> annotations are the more important content, online item to peruse: 
> <http://nrs.harvard.edu/urn-3:HUL.ARCH:10346976>http://nrs.harvard.edu/urn-3:HUL.ARCH:10354445?n=8) 
> and finally my simplest case (annotated by former owner: 
> http://lms01.harvard.edu/F/?func=find-b&find_code=SYS&request=1079611) 
> Some special collections notes apply to all examples of the work while 
> some apply to only the item in hand.
>
>
> Does anyone know what BIBFRAME intends to do about these and similar 
> cases?
>
>
>
> Kate Bowers
> Collections Services Archivist for Metadata, Systems, and Standards
> Harvard University Archives
> Cambridge, Massachusetts, USA
> voice: (617) 384-7787
> fax: (617) 495-8011
> [log in to unmask]
>
>
>
>
>
> ------------------------------------------------------------------------
> *From:* Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask]> on behalf of Hess, Kirk <[log in to unmask]>
> *Sent:* Tuesday, November 10, 2015 3:24 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
> Item connects bibliographic descriptions to other library-centric data 
> domains like circulation, which I think was what made this challenging 
> to model. The key things in this proposal to me were items have 
> identifiers, a barcode/electronic locator and have relationships to 
> other resources which arenít bound by a fixed number of levels.
>
> I agree properties like subLocation are incomplete and would be more 
> fully described in a working system or a future version of the 
> vocabulary. In that particular case maybe we should use the 
> usageAndAccess pattern, with subLocation expecting a Location class?
>
> I also imagine an implementer would extend bf:Item and add those three 
> properties you mentioned as local properties. A few months ago I 
> reviewed the Kuali OLE item table and there were about 20 
> circulation-type fields, so itís going to take a lot more properties 
> to address those two tasks.
>
> -Kirk
>
> *From:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *On Behalf Of *Joseph Kiegel
> *Sent:* Tuesday, November 10, 2015 1:39 PM
> *To:* [log in to unmask]
> *Subject:* [BIBFRAME] Properties of Item proposal
>
> Items in BIBFRAME may serve different purposes, which is not addressed 
> in the Items proposal.  A relatively narrow purpose is to support the 
> user task /obtain/, while a more complex one is to support a working 
> circulation system.  The properties elaborated in the proposal are not 
> sufficient even for the user task /obtain/.  Here are comments on them.
>
> bf:electronicLocator:  should the expected value be a URI?  It seems 
> odd to express URLs as literals in linked data.
>
> bf:heldBy and bf:subLocation:  the MARC holdings format and many 
> library systems recognize three levels of location information: 
> organization, library and sublocation within a library.  BIBFRAME 
> should support the same number of levels:  for example, it should add 
> a property such as bf:location, which is intermediate between 
> bf:heldBy and bf:subLocation.
>
> bf:heldBy University of Washington Libraries
>
> bf:location:  Art Library
>
> bf:subLocation:  Reference stacks
>
> bf:heldBy University of Washington Libraries
>
> bf:location:  Engineering Library
>
> bf:subLocation:  Reference stacks
>
> Without bf:location, reference or general stacks locations in 
> different buildings appear to be the same.
>
> bf:itemOf:   is a reciprocal property needed?  For example, 
> bf:hasItem, a property of bf:Instance with an expected value of bf:Item.
>
> Two properties are lacking from the proposal: bf:itemStatus and 
> bf:circulationCharacteristic
>
> bf:itemStatus:  it is crucial to inform users of the status of an 
> item, e.g. available, checked out, missing, withdrawn, at the bindery, 
> etc.
>
> bf:circulationCharacteristic:  another important aspect of materials 
> is the general policy that governs them, e.g. circulating or library 
> use only.  It is tempting to try to include this characteristic in 
> bf:itemStatus, but they are independent aspects.  LUO materials may be 
> missing, at the bindery or even checked out (e.g. faculty loans of 
> reference materials).
>

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