Thanks for this, Tim! Very good points.

A question that I hope will be illuminating as to why I feel that the current Work-as-Description doesn't work in RDF:

I have an image or other digital resource (an e-book, perhaps) and want to use BibFrame to describe it.
The bf:Instance for this image could legitimately have a media type, and the answer as to what that media type is depends on what the Instance's URI actually identifies.

If the Instance's URI identifies the RDF Description, then the media type will be application/turtle, application/ld+json, application/rdf+xml and so forth.
If the Instance's URI identifies the Image, then it would be image/jpeg, image/png, image/gif or similar.

But it cannot be both at the same time.  This is the restriction that a URI MUST NOT identify two different resources at the same time -- in this case the abstract Instance and the RDF document that serializes the part of the graph that describes that abstract Instance.

Equally, creator -- the creator of many many RDF documents is likely to be the BibFrame converter.  The BibFrame converter is highly unlikely to have created many abstract Works.

In order to express information about the abstract Work, abstract Instance, real world Person, and so forth, there MUST be a URI that identifies that object.  If the URI that has the class bf:Work is not that, then we need another URI.


On Thu, Jan 15, 2015 at 11:59 AM, Tim Thompson <[log in to unmask]> wrote:
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!):

<> a bf:Text, bf:Work ;
    bf:authorizedAccessPoint "Rosanvallon, Pierre, 1948- Démocratie inachevée" ;
    bf:derivedFrom <> .

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

<> a bf:Annotation ;
    bf:annotates <> ;
    bf:changeDate "2014-12-31T16:04" ;
    bf:derivedFrom <> .

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 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.


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



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 ( - 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 for more information.


For real-world interaction with an r-ball, register for the Jane-athon at ALA Midwinter! (






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?



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! :)





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. 





 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 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]
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305