On the first page of the Items proposal, a number of statements are made about the class bf:Item. In particular, bullets 3 through 6 introduce the concepts of simple and compound items. However, the term “compound item” is used to mean both a single bf:Item and a graph of bf:Items (see the end of this message for a close reading of the bullets).
There are two problems with these bullets: they are confusing, and they do not tell us how to apply the bf:Item class and its properties. Confusion arises because “simple” and “compound” have no basis in the ontology: there is only one Item class, and all instances of the class have the same properties.
A better approach is to provide use cases that show how the class and its properties are meant to be applied. I think the terms compound, simple and component do have a place as a shorthand to aid human understanding, and I would define them this way:
Compound item: a bf:Item linked to one or more Items through the bf:hasComponent property.
Simple item: a bf:Item not linked to other Items through the bf:hasComponent property.
Component: a bf:Item linked to another Item through the bf:componentOf property. A component may itself be simple or compound.
Note that definitions of these terms cast in this way are about relationships among items; all of the items are members of the same class.
Here are common use cases with examples of how the proposal could be applied.
Case 1: single volume monograph with one copy in a single location
Case 2: serial or multivolume monograph
Compound item with components. The compound item may have bf:enumerationAndChronology that serves as a summary holdings statement.
Case 3: analyzed serial/multivolume monograph
Serial/set – simple item that may have bf:enumerationAndChronology that serves as a summary holdings statement
Analyzed volumes – simple item or compound item with components, depending on whether the analytic is a single volume or a serial/multivolume monograph.
Case 4: single volume monograph with multiple copies in the same location
This is an interesting case that may be modelled in different ways: either as multiple simple items, or as a compound item with components.
Additional use cases include partially analyzed serials or multivolume monographs, and single volume monographs with accompanying material shelved in the same location, e.g. a book with a disc in a separate container
Bullet 3: “A bf:Item is referred to informally as a simple item or a compound item.” In this sentence, a compound item is clearly a single bf:Item.
“A compound item consists of multiple Items, each of which is itself an Item.” Here a compound item is a graph of bf:Items.
“We refer informally to each part of a compound items [sic] as a component.” Again, a compound item is a graph, since it has other Items in it.
Bullet 4: “The components of a compound item may be simple or compound.” A compound item in this bullet is a graph because each component is itself a member of bf:Item.
Bullet 5: “Thus, a compound Item functionally serves the purpose of what was previously HeldMaterial; that is, a compound Item may be thought of, informally, as a summary description of several Items.” It is hard to tell which sense is intended here. A single item with a bf:enumerationAndChronology property may serve as a summary description, or a graph of items may be interpreted as a summary holdings statement.
Bullet 6: “Properties bf:hasComponent and bf:componentOf are defined. bf:hasComponent is a property of a compound item.” The compound item here must be a single bf:Item, since properties are associated with classes not with graphs.
“It [bf:hasComponent] points to the item’s components.” Somewhat hard to tell, but components were defined in Bullet 3 as parts of a graph so the compound item here seems to be a graph.
“Property bf:componentOf is a property of an item which is a component of a compound item and it points to the compound item.” A compound item here means a single item, not a graph, because the expected value of bf:componentOf is bf:Item.