Print

Print



Sorry to reply to my own message, but ...

Equally it may be helpful to consider it from the other end.  What if I *do* have an identifier for the physical object?  How do I link the HeldItem record-thingy* to it?  And if I have an identifier already, and can associate properties and relationships with it, what use is the HeldItem? :)

* Kate, the term used most often is "resource".  As in the R in URI (Uniform Resource Identifier) or URL. But record-thingy has a much nicer ring to it ... and the same initial letter! :)

Rob


On Tue, Jan 13, 2015 at 3:35 PM, Robert Sanderson <[log in to unmask]> wrote:
Hi Nancy,

I'll try and explain, apologies for my lack of clarity!

On Tue, Jan 13, 2015 at 2:54 PM, Fallgren, Nancy (NIH/NLM) [E] <[log in to unmask]> wrote:

Hi Rob,

I contend that currently, according to the vocabulary, the Annotation is the RWO. In particular, it has properties like bf:barcode (Identification number of the physical item) and bf:circulationStatus (Circulation status of an item).  The holdings record does not have a barcode, nor is it an annotation for that matter.

 

My understanding is that the HeldItem annotation corresponds more or less to what we currently catalog as an item record, which is not the same thing as a holdings record.  A holdings record is a summary of the items held by a library that are members of a particular manifestation, which may also include data common to all the members. 


My understanding of Holdings is, and please correct me:  A collection of physical objects, owned by a single institution, all of which are instances of a particular bf:Instance (or frbr:Manifestation). So if you had two copies of a book, from two different printings (say 2010 and 2012), you'd need to have two Holdings records, otherwise when you relate it to your Instance/Manifestation, you'd be inheriting the wrong print date for at least one of the copies.

So this isn't what I'm talking about with respect to HeldItem and I mispoke in my response to Karen :)  My experience with the holdings side of the house is very limited.

 

My understanding is that the current holdings record more or less corresponds to the HeldMaterial annotation.  HeldItem is a subclass of HeldMaterial (and therefore a sub-subclass of Annotation).  Properties like bf:barcode and bf:circulationStatus are appropriate to HeldItem.  And equally appropriately, HeldMaterial should not have those properties.  So, I’m a little confused about what you’re objections are (which is not to say that I think items are well modeled in BF, just that I don’t understand your response to Karen). 


My objections are:

1. Annotation is not an appropriate base class for this, regardless of whether it's a record or a real world object.  
This is my primary concern. The thing with a barcode is not "about" the Instance. There's no comment or body of the thing with the barcode. 

2. For the same reasons that we should not persist the notion of authority records, we should equally drop the notion of holdings/item records and simply identify and describe what we're concerned with.

I want to be able to make assertions about books in the same way that I want to make assertions about people, locations, events, and all of the other things we hold dear.  Say I take a photograph of the book. I want an identifier in order to say <photograph> <depicts> <book> ... not <photograph> <depicts> <item-record> ... that would be a very different photograph, likely of a computer screen :) 

 

 If I can describe a book/Instance by saying that it has an isbn, why can’t I describe an item/HeldItem by saying that it has a barcode?  Why does it matter that the book/Instance is not a single physical entity and the item/HeldItem is?  It seems to me that the HeldItem annotation is simply additional description at a more granular and only locally relevant level. 


Sure, if the definition of HeldItem is something like "A record that holds information about a particular physical object that's only locally relevant" then no problem. But why use linked data for something that's only locally relevant? And why not simplify the definition to just "a particular physical object" and describe it directly?  Practically all of the current properties make sense already, it's not even a big change :)

It's the same discussion that Kevin and I had about bf:Person last year, and whether bf:Person, which hasAuthority an Authority that identifiesRWO the real person, could actually just cut to the chase and _be_ the real person. 

Rob


 From: Robert Sanderson [mailto:[log in to unmask]

Sent: Tuesday, January 13, 2015 4:02 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Annotations in BibFrame

 

 

Hi Karen,

 

On Tue, Jan 13, 2015 at 12:28 PM, Karen Coyle <[log in to unmask]> wrote:

On 1/13/15 8:17 AM, Robert Sanderson wrote:

I'm less concerned about exact definitions and more about the last case of HeldItem as a subClass of Annotation.  Regardless of the exact definition, I suggest that it is impossible for the same resource to be both a real world physical object and a digital annotation at the same time. 

This tells me that part of the definition of Annotation is that the annotation body is a digital object, not a real world object (RWO). And you contend that holdings information is a RWO. Have I understood your meaning correctly?

 

Almost. The annotation itself is a digital object, the body could be anything. The model in BibFrame is that HeldItem is a subClass of bf:Annotation, which has a bf:annotationBody.

 

I contend that currently, according to the vocabulary, the Annotation is the RWO. In particular, it has properties like bf:barcode (Identification number of the physical item) and bf:circulationStatus (Circulation status of an item).  The holdings record does not have a barcode, nor is it an annotation for that matter.

 

If so, then my reply is truly in the definitions: Are there truly RWOs in library data?  Library data has personal names, not persons. Book titles but not books.

 

Which I have previously argued is incompatible with Linked Data, as it is centered around resources not strings.  Or at the very least, any advantage of using Linked Data is lost when you use it only as a 1:1 transliteration of MARC's strings.

 

Holdings data is a particularly odd one because there's a mixup between holdings (what library owns a resource and where it is located in the library) and item-level descriptive information (which is relatively rare in libraries but is primary in archives and museums).

 

Absolutely agree.  

 

Logically, there is a RWO, but illogically its physicality is described in what is defined in the cataloging rules as an abstract entity for a class of things (FRBR:Manifestation or BF:Instance). The actual physical item is often asserted solely by the presence of a barcode number. With this model, information about holdings (e.g. location) is just a digital resource that says something about another digital resource.

 

To return to my litmus test, what is the creation date of the resource?  If it's the creation date of the record, then I agree (and think the we need to change the model).  If it's the printing date of the physical object, then it's not the digital resource.  

 

 

The larger question is: should library catalog data address "real world objects" and, if so, what are those objects? The multi-entity models, FRBR or BF, make this an even harder question, IMO, because there is nothing that represents the whole that the RWO is. Delegating the RWO to an annotation is pretty bad; not recognizing that the library description is more than an abstraction with a bar code is worse.

 

If there is any thought to integrate with Archival, Museum, Gallery and similar cultural heritage or memory institution data, or beyond our natural partners to other institutions, then we absolutely must engage with this question.  If we wish to remain our own special, unique and never-re-used snowflake, then we can persevere with our arcane distinctions that were only ever introduced to save bits due to a format designed for tape storage.

 

Rob

 

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305




--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305