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.


On 11/12/15 6:17 AM, Bowers, Kate A. wrote:
[log in to unmask]" type="cite">

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)† and this (where annotations are the more important content, online item to peruse: 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.


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