Print

Print


Kate

 

This is a timely question.

 

I gave a presentation on "What is an RDA record?" at a forum at ALA 2014
which essentially discusses what an RDA "thingy" is
(http://www.gordondunsire.com/pubs/pres/WhatRDARecord.pptx - has animation
and notes not available in the slideshare version). I expect a BIBFRAME
thingy to face similar issues.

 

I have recently started to use the term "r-ball" for "thingy record". It is
best pronounced with a rolling "r" - as in "Captain, the r-r-r-r-r-balls
have lost expression!" (apologies to Scotty) - because it can stand for
record, resource, RDF, RDA, and RIMMF: see http://rballs.info/ for more
information.

 

For real-world interaction with an r-ball, register for the Jane-athon at
ALA Midwinter! (http://rballs.info/topics/p/jane/janeathon.html).

 

Cheers

 

Gordon

 

From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Bowers, Kate A.
Sent: 14 January 2015 04:17
To: [log in to unmask]
Subject: Re: [BIBFRAME] Annotations in BibFrame

 

The resource is the resource.  

BIBFRAME is some metadata about the resource.

So, when you have some metadata brought together in the BIBFRAME framework,
what do you call this brought-together metadata?  

 

In short, is a BIBFRAME thingy called a "record" or is it called something
else?

 

Thanks!


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 Robert Sanderson
<[log in to unmask]>
Sent: Tuesday, January 13, 2015 6:59 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Annotations in BibFrame 

 

 

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