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