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