Let me address some issues raised last week over the Annotation model. I can see that I created some confusion, I take responsibility for that because I released bits of information without releasing the whole draft, which is not quite yet ready for release, but which I think will relieve some of the apprehensions. I did so understanding the risk that it would cause some confusion but I thought it worthwhile, because I felt the need to respond to direct questions that were posted (for example, by Karen) rather than stay silent and give the impression that nobody was listening. More to the point some of the questions assumed characteristics of the first draft that no longer apply and I felt it only fair to point these out, and particularly for Karen, as she indicated that she is doing research that is based on the first draft. So, a few observations. Definition new classes The Annotation model is just that. A model. It is not a specification (or it would be called the BIBFRAME Annotation Specification). There are four use cases presented - and correspondingly, four Annotation classes - which are used to drive the model. They are not intended to present the full scope of use cases nor all of the possible Annotation classes, they are intended to provide sufficient material to develop a model. There will be prose in the document that makes this clear. There is nothing to prevent the definition of additional classes. If at some point the Annotation model becomes "official", that will NOT mean that a new Annotation class will require a new version of the Annotation model. A new Annotation class and corresponding properties can be added to the BIBFRAME Vocabulary. The question of how that's done - i.e. the process by which new BIBFRAME classes and properties are defined - is beyond the scope of the Annotation model to answer, but whatever process is used to add classes and properties for Works and Instances, the same process would apply for new Annotation classes and their properties. Use of non-BIBFRAME classes and Properties within a BIBFRAME Annotation Annotation classes and properties from other namespaces may be included within a BIBFRAME Annotation. For example: <http://library.local.org/annotationXYZ> a bf:Annotation; a em:Watcher; em:pingback <library.local.org/examples/king/test001/w1>; bf:annotationAssertedBy <library.local.org/em>; (Where em:pingback might be defined as a subproperty or bf:annotates.) Class vs. Motivation, and oa:hasBody There is nothing to preclude the use of an OA motivations in a BIBFRAME Annotation. There is nothing to preclude the use of oa:hasBody. One could use a BIBFRAME Annotation to "tag" a resource, For example: <anno1> a bf:Annotation ; oa:motivatedBy oa:tagging ; oa:hasBody <tag1> ; bf:annotates <target1> . The model will explain that there is no limitation against doing this. BF Subproperties of OA Tom Baker's message: http://listserv.loc.gov/cgi-bin/wa?A2=ind1307 <http://listserv.loc.gov/cgi-bin/wa?A2=ind1307&L=bibframe&T=0&X=1C46017D52D3 01FFC7&P=3878> &L=bibframe&T=0&X=1C46017D52D301FFC7&P=3878 points out that an OA Annotation may have multiple bodies. So if we were to declare for example that the two properties, bf:hasCoverArt and bf:hasCoverartThumb, were both subproperties of oa:hasBody, then a cover art Annotation which incudes both (i.e. a link to cover art as well as to a thumbnail) could be viewed from an OA perspective as an Annotation with two bodies. I knew that an OA Annotation could have multiple bodies but I hadn't thought through the implications of that quite in these terms. Tom's argument is convincing enough for me. So we will define all BIBFRAME Annotation-class-specific properties to be subproperties of oa:hasBody. And, we will define bf:annotates to be a subproperty of oa:hasTarget. I appreciate the comments on and discussion of BIBFRAME Annotations and we hope to have draft 2 of the model ready to review soon. Ray