Jeff Young and I have discussed Ray's proposal to add 'Item' as a class to BIBFRAME.  We think it's a good idea. Items are important real-world things in the domain of library resource description, and they need to be addressed separately from Instances or Manifestation-like objects. And they need to be discussed in contexts other than holdings. In the new proposal, items are treated in an ontologically more natural way. The original BIBFRAME definition of 'Item' as a 'holding' relationship between an Instance and an Annotation in the original model was awfully hard to get our heads around.


We just have a couple of questions and suggestions for making this part of the BIBFRAME model more machine-processable. 


Questions and minor issues

  • ​How are the properties partitioned among 'Instance and 'Item'? The example described in the Proposal document implies that the 'Item' class contains only properties indicating uniqueness -- such as shelf location, bar code, etc -- while Instance would contain properties such as 'contributor,' 'creation date,' and 'custodial history.' Is this correct? Or is there any bleeding between the Instance/Item line? For example, can an Item have an author or title, or is that information always maintained in the corresponding Instance description?
  • We're not sure what these sentences mean, in literal modeling terms: ​

"The first removes the strong coupling of holdings and annotations; they remain loosely coupled. A bf:Item may be created and exist without being an annotation, or, it may be submitted as the body of an annotation." 

Are there co-occurrence requirements between Items and Holdings? The concepts were certainly intertwined in the original BF model, but now they are not. In what formal respect are they still 'loosely coupled'?

  • ​​Some minor quibbles with the property list: 
    • bf:hasCondition  -- should it be a property of the class bf:UsageAndAccessCondition?
    • bf:heldBy and bf:holdingOrganization. Are these reciprocal properties? If so, should the expected value of bf:holdingOrganization be bf:item?
    • bf:subLocation -- should the expected value be a URI instead of a string?
    • In the example we discuss below, the subLocation is modeled as an Organization with properties. This solution would support the formulation of queries about all of the items held by the Prints and Photographs Division, Washington DC 20540 USA. But if bf:subLocation is a string, it would have to be copied into the description of every Item held in the collection, which would introduce transcription errors and obscure the essential 'Thing-' ness of the object being described.
  • ​We recommend a slight refactoring of the instance data to eliminate a blank node.



         bf:heldBy [

             a bf:Organization ;

             rdfs:label "DLC"; 

             bf:holdingOrganization "<>/].




bf:heldBy <>.



a bf:Organization ;

   rdfs:label "DLC" ;



A quick sketch

We took the example presented in the 'BIBFRAME Item Proposal' document and re-coded it with corresponding statements expressed in Our example is based on Dan Scott's 'schema as Offer' model of holdings.This data might not serve any useful purpose, but we devised it as a way to visualize the strengths, weaknesses, and the potential for alignment of the two models.

The first RDF block shows the primary entity, a collection of photographs held at the Library of Congress. It is modeled as a multi-part Item containing two items: #2 and #3. Item #2 exists only as a physical photograph. Item #3 exists as a physical and a digital photograph. (We simplified the original example somewhat.) 

The comments below apply to item #3.


Primary Entity


<> # "Daguerreotypes collection 1840-1860"

    a bf:Item ;

    a schema:CreativeWork ;

    a schema:IndividualProduct ;

    bf:hasComponent <>  ; # "item 2 (physical)"

    bf:hasComponent <>  ; # "item 3 (physical)"

    bf:hasNote _:A1 ; # "Daguerreotypes collection 1840-1860"

    bf:heldBy <>  ; # "Library of Congress - Prints and Photographs Division"

    bf:usageAndAccess <>  ;

    rdfs:label "item 1 (a 'Compound Item')" ;

    schema:hasPart <>  ; # "item 2 (physical)"

    schema:hasPart <>  ; # "item 3 (physical)"

    schema:name "Daguerreotypes collection 1840-1860" ;

    schema:offers <>  ;

·       ​The descriptions of the physical and digital items are the same, except that the physical item has a serial number and the digital item has a URL.

·       The physical and digital photographs are associated with a single bf:Instance (and corresponding schema:ProductModel). In the above snippet, the bf:Item is connected to the bf:Instance with the bf:itemOf property (corresponding to schema:exampleOfWork). But the Instance description shown below contains only the reciprocal schema:workExample property, which connects the description of the more abstract thing to the more concrete one. What is the corresponding BF property? Should it be something like bf:hasItem? 


    a bf:Instance ;

    a schema:Photograph ;

    a schema:ProductModel ;

       schema:workExample <>  ; # "item 3 (physical)"

       schema:workExample <>  ; # "item 3a (digital)"

·      This snippet supports our claim that bf:Instance and our use of schema:ProductModel align around a Manifestation-ish object. But it is perhaps controversial to claim that the physical and digital item represent the same Manifestation because they don't have the same serial number or other product id. Another option is that they are 'examples' of the same Work, which could be expressed in the OCLC Schema model. But in FRBR terms, we would be skipping a level (or two). Is that a problem for BF? 

·        As the above discussion implies, many of the high-level concepts can be mapped transparently between the two models. Some correspondences:

o   bf:Item and schema:IndividualProduct, 

o   bf:Instance and schema:ProductModel,

o   bf: and schema:Organization,

o   bf:hasComponent and schema:isPartOf, 

o   bf:electronicLocator and schema:contentURL 

·        ​But there are slight differences in the interpretation of some of the string literals, which would create problems for the mapping of instance data because the properties differ in specificity.

o   In the Schema model, the name of the collection is "Daguerrotypes collection 1840-1860," and the individual photograph has "DAG no. 1410" as a serial number.

o   In the BF model, the first is expressed as the object of bf:hasNote, and the second as the object of bf:identifiedBy.

o   In other words, schema:name is more specific than bf:hasNote, and schema:serialNumber is more specific than bf:identifiedBy.

·        The main difference between the two models is in the treatment of the holdings description.

o   In the Schema model, all of the details are in the Offer, such as the name of the holding institution, the terms of the offer, and the location of the item.

o   In the BF model, holdings data is identified as a set of properties on the Item -- 'usage and access,' 'held by,' etc. Perhaps this is what is meant by the BF claim that Item and Holding are still loosely coupled. In the Schema model, they are less so.

o   The relative merits of the two models is open to discussion, but we can point out that that the Offer model enables more than one set of access restrictions -- for example, one for students and another for faculty members.


  • The string object of bf:subLocation “Prints and Photographs Division, Washington DC 20540 USA." is modeled as structured data that refers to the properties schema:Organization and schema:Address.
    • The Prints and Photographs Division is linked to the Library of Congress with the reciprocal properties schema:subOrganization and schema:parentOrganization.
    • The holdings information (spelled out in schema:Offer) is associated with the subOrganization.
    • The subOrganization has its own address (Washington DC 20540).
    • These statements could be modeled in BF with the addition of properties that describe hierarchical organizations, and a class describing a structured postal address.



We welcome your comments.​

Jean and Jeff