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
"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'?
a bf:Organization ;
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 Schema.org. 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.
a bf:Item ;
rdfs:label "item 1 (a 'Compound Item')" ;
schema:name "Daguerreotypes collection 1840-1860" ;
· 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 ;
· 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.
We welcome your comments.
Jean and Jeff