Apologies for my silence; we have indeed been thinking deeply about BIBFRAME annotations.

Several months ago the W3C convened a working group on Web Annotations, co-chaired by Rob.  This is  a major step towards a standard generic data model for annotations.  I have joined the working group,  in part to support BIBFRAME and my purpose in that respect is twofold. One, to determine to what extent web annotations, when stable, will support BIBFRAME. The more it does, the less work for BIBFRAME, and I am far more confident about that than I was a couple years ago.  But there is still a long way to go before we can properly assess this. Second, I hope to bring the BIBFRAME perspective to the web annotation group and hopefully help to inform the process.   I have so far brought several use cases to the group, with mixed reactions, but we’re working through it.

It is my hope, for example, and I am optimistic, that Review and Description may no longer need to be BIBFRAME annotation classes, since (as Rob has noted) reviewing and describing are things commonly done on the web and will be done by annotating.

Now consider table of contents (and while we’re at it, cover art).  As Rob says, there is only one “right answer” for table of contents, it is not institution specific, and (for the sake of discussion) let’s concede that point.   The point is, the table of contents is not part of the resource being annotated (nor is cover art).

That takes us to the question at hand: what is the resource being annotated?

A book “Gone With the Wind” is an abstract resource.  A bf:Work, i.e. a BIBFRAME Work,  is an RDF description of the book “Gone with the Wind”.  The bf:Work is a BIBFRAME resource.  The abstract book “Gone With the Wind” is not a BIBFRAME resource.   It is the bf:Work that is being annotated.  Typically  the bf:Work does not include a table of contents for the abstract Work it describes.  (There may be a table of contents in a note, but typically not.) Nor does it include cover art.   The book itself might include these things but the BIBFRAME description does not.  So these things annotate the BIBFRAME description.

Now for HeldItem.  At the risk of oversimplification -- and please correct me if I am misrepresenting what you are saying, Rob --  the objection can be exemplified by properties like bf:circulationStatus and so on. The argument is:
“bf:circulationStatus is intended to convey the circulation status of an item, but it is a property of an annotation, and the concept of circulation status of an annotation is nonsensical. “  Does that adequately summarize the argument?

I don’t find that argument compelling.   Bf:circulationStatus does not need to be defined as “the circulation status of the annotation” it can be defined as “the circulation status of the item being annotated”.   Couldn’t it?

In  any case, representing holdings information as annotations does seem to have caused much angst, and we are considering ways to model this differently.   In fact the BIBFRAME annotation model and specification will be revisited in its entirety, but that effort is on “hold”  for now, pending a bit more progress on the W3C work.