Print

Print


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