We have been having a higher-level discussion of annotations and holdings in BIBFRAME.  I decided to look at the classes and properties in BIBFRAME in an attempt to evaluate their suitability for holdings.

 

Here’s what the model is today.

 

Class HeldMaterial – subclass of Annotation

 

Properties with the domain HeldMaterial:

holdingFor

electronicLocator

enumerationAndChronology

heldBy

subLocation

accessCondition

lendingPolicy

reproductionPolicy

retentionPolicy

 

Properties with the range HeldMaterial

componentOf

 

Class HeldItem – subclass of HeldMaterial

 

Properties with the domain HeldItem

componentOf

shelfMark

shelfMarkDdc

shelfMarkLcc

shelfMarkNlm

shelfMarkScheme

shelfMarkUdc

barcode

circulationStatus

copyNote

itemId

 

HeldItem inherits the properties of HeldMaterial, which means that properties requiring HeldMaterial as a domain are satisfied by HeldItem.  (That is, any instance of HeldItem is also an instance of HeldMaterial, by the definition of subclass.)

 

Purpose and Use of HeldMaterial and HeldItem

The definitions of HeldMaterial (“Summary holdings information”) and HeldItem (“Item holdings information”) are open to interpretation.  But, assuming a standard library approach and a desire to provide known library functionality, an obvious interpretation is that HeldMaterial represents a holdings record and HeldItem represents an item record.  Other approaches may be taken but I will look at how well BF works from this point of view.

 

HeldMaterial

The properties associated with HeldMaterial match up rather well with the MARC holdings record.  Institution, shelf location, lending and reproduction policies, and a summary holdings statement are present.  The lack of a call number is not necessarily a critical problem.

 

Missing elements:  The obvious missing element is a mechanism to encode detailed holdings, e.g. in support of machine processing for ILL.  Also, subLocation should support two levels in a machine-actionable way:  building and shelving area, since we need to differentiate, e.g., the general stacks of Branch A from the general stacks of Branch B.  The model also lacks the ability to support acquisitions or checkin operations.

 

HeldItem

The properties associated directly with HeldItem are good:  they are the ones needed for public display of basic information.  Flexibility is built in for multivolume titles where some volumes have different values by using inherited properties from HeldMaterial:  for example, different locations, access conditions, lending policies.

 

Missing elements:  there is not enough information to support a circulation system:  e.g. material type and loan type are missing.  Volume numbering of individual volumes is also missing:  it is risky to use enumerationAndChronology because that seems to be for summary holdings statements.

 

From: [log in to unmask] href="mailto:[log in to unmask]">Karen Coyle

Sent: Saturday, January 17, 2015 9:19 AM
To: [log in to unmask] href="mailto:[log in to unmask]">[log in to unmask]
Subject: Re: [BIBFRAME] Annotations in BibFrame

Thanks, Francis - the archival perspective is important because it brings up the question: are all of our things 'same enough" to fit into a single definition of Work/Instance/Item?

One way to approach this is to encourage multiple "views" - the book people can have an Item graph that has a barcode and a note about a torn page; the archival folks (and art and museum folks) can have a rich item with dimensions, physical composition (marble, oil paint).

Where we seem to run into problems is when we try to impose a single model (dimensions are Instance level only) on everything.

And if this sounds like creating a lot of incompatibility, there are ways that we can pay attention to each other's data without getting involved in each other's structures, because any statement can potentially live comfortably in any number of graphs. (And from here on, we need pictures to describe this, so I'll stop.)

kc

On 1/16/15 5:57 AM, Lapka, Francis wrote:
[log in to unmask] type="cite">

While I am sympathetic to the Bibframe desire to keep its core model as simple as possible, I agree with Rob’s original assertion, supporting his Option 2 (… make HeldMaterial a subclass of bf:Resource …”).

 

We shouldn’t impose the entire complexity of the FRBR/RDA models upon Bibframe, but an Item is an entity with a robust set of attributes that logically deserves to be a subclass of bf:Resource. As Karen noted earlier, this is especially true for special collections (rare books, archives, museums), where description of item-level information is vital.

 

It’s worth noting that the bf:Instance includes at least three attributes that more rightly describe an Item (if we conceive of Instance as a Manifestation—an abstract class): custodialHistory, immediateAcquisition, local.

 

Additionally, bf:Instance includes a number of attributes that are equally appropriate to the description of Items, but for which no equivalent is currently provided by bf:HeldMaterial. These include (and there may be others): descriptionConventions (and 6 other “description…” attributes), dimensions, genre (for item-specific characteristics, such as “Extra-illustrated copies”), hasAnnotation,  hasPart and partOf (for aggregates, e.g. bound-withs), preferredCitation, relatedAgent (to record former owners, etc.).

 

Francis

 

 

Francis Lapka  ·  Catalog Librarian

Department of Rare Books and Manuscripts

Yale Center for British Art

203.432.9672  ·  [log in to unmask]

 

 

From: Tim Thompson [mailto:[log in to unmask]]
Sent: Thursday, January 15, 2015 3:00 PM
Subject: Re: Annotations in BibFrame

 

The current MARC-to-BF conversion routine also embodies the kind of indirection that Ray describes. If you convert a MARC record[1] using LC's online converter, you will see things like this[2] (by the way, the converter now offers N3 serialization--nice!):

<http://bibframe.org/resources/FuE1421349519/8120033> a bf:Text, bf:Work ;
    bf:authorizedAccessPoint "Rosanvallon, Pierre, 1948- Démocratie inachevée" ;
    bf:derivedFrom <http://bibframe.org/resources/FuE1421349519/8120033.marcxml.xml> .

So, this "bf:Work" was actually derived from a MARC record. You'll also find a bf:Annotation that confirms this:

<http://bibframe.org/resources/FuE1421349519/8120033annotation20> a bf:Annotation ;
    bf:annotates <http://bibframe.org/resources/FuE1421349519/8120033> ;
    bf:changeDate "2014-12-31T16:04" ;
    bf:derivedFrom <http://bibframe.org/resources/FuE1421349519/8120033.marcxml.xml> .

The abstract Work being described here was obviously not itself derived from a MARC record (that would be pretty twisted), ergo the bf:Work must be something else, its own self-referential thing, representing an act of description rather than a real world entity (at least that's the way things have been modeled in the conversion algorithm). So, BF classes are not surrogates of things, but surrogates as surrogates? This all seems very postmodern. . . . The whole problem always seems to come back to the desire to carry MARC over into linked data (doomed to failure) rather than seeking to remodel the bibliographic universe in light of the new vistas and affordances that link data has to offer.

Regarding bf:Instance and bf:HeldItem, I'm not sure I necessarily see a problem with holdings info as an annotation. Setting aside the issue of what a BF class actually refers to, let's assume that a bf:Instance really does represent something in the real world. That something would seem to be a hybrid entity (the intersection of FRBR Manifestation and Item?), with both abstract and physical characteristics. Why couldn't holdings and item-level information, then, be construed as local overlays upon or "customizations" of a general bf:Instance? Analogous, say, to a sequential human anatomy chart with layered transparencies?

Tim

[1] http://bibframe.org/resources/FuE1421349519/marcxml.xml
[2] http://bibframe.org/resources/FuE1421349519/bibframe.n3


--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

 

On Thu, Jan 15, 2015 at 10:28 AM, Karen Coyle <[log in to unmask]> wrote:

I like the "r-ball" ;-).The W3C Shapes group (the one looking at vaidation for RDF) is also struggling to come up with a good term for "the thing that you want to possess as a unit of information". So far the words "graph" and "node" are popular among those folks. A graph is just a group of triples that you are calling "my group of triples for this thing I want to do." The more difficult question is how to gather those triples in a machine-actionable way -- and there the popular solutions are: named graphs, and rdf:types.

The nice thing about the graph and node concepts is that they allow you to address a more dynamic concept of what matters to you in a particular context and at a moment in time. "Record" carries some baggage from the time that what is a "valid record" is defined once, for all records and for all time. Although database technology has always allowed you to dynamically extract selected bits of data from the database, (which we do in library systems for displays, for example) most of us didn't think of those as records, because the only record - the one record to rule them all - was the MARC record. In fact, we've been messing with "records" that aren't MARC for every system function, but we don't have a name for them. r-ball would be perfect for those, as well.

kc



On 1/14/15 1:37 PM, Gordon Dunsire wrote:

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

 

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

 


-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600